尧图网页设计 
graphify 实战指南:GitHub 仓库克隆、多子目录图构建与跨仓库图合并【免费下载链接】graphifyTurn any codebase, with its docs, SQL schemas, configs, and PDFs, into a queryable knowledge graph. A /graphify skill for Claude Code, Cursor, Codex, and Gemini CLI: local deterministic AST parsing, every edge explained, no vector store.项目地址: https://gitcode.com/GitHub_Trending/graph/graphifygraphify 的 Claude Code skill(graphify/skills/claude/)内置了一套从 GitHub 拉到本地、多仓库/多子目录各自建图、再合并为单一可查询知识图谱的工作流。本文基于 github-and-merge.md 参考文档展开,逐条给出可复制的命令,并结合 graphify/cli.py、graphify/build.py、graphify/cross_repo_types.py 的源码实现,讲清graphify clone与graphify merge-graphs背后的目录约定、节点前缀规则和跨仓库类型连接机制。读完本文,你可以把任意多个 GitHub 仓库或 monorepo 中的多个服务目录,合并成一份带repo属性、可直接用graphify query查询的跨仓库图。适用场景与触发条件根据参考文档开头说明,这份工作流在两种情况下加载:用户传入了一个或多个https://github.com/...URL(需要先把仓库拉到本地);用户指定了多个本地子目录(例如 monorepo 或 multi-service 布局),希望合并成一张图。也就是说,它覆盖远程仓库入口和本地多目录入口两条路径,最终都收敛到同一个动作:用graphify merge-graphs把多份graph.json合并,之后所有代码库问题直接走graphify query查询合并图,无需重新抽取。Step 0:用 graphify clone 克隆 GitHub 仓库文档给出的单仓库用法是:LOCAL_PATH$(graphify clone github-url [--branch branch]) # Use LOCAL_PATH as the target for all subsequent stepsclone子命令把本地路径打印到 stdout(见 cli.py 的 clone 分发逻辑:_clone_repo(...)返回路径后直接print(local_path)),因此可以用命令替换捕获为LOCAL_PATH,后续步骤以它为扫描目标。从源码 graphify/cli.py#L866-L922 的_clone_repo实现看,该命令有几个明确的行为约定:目录约定:默认克隆到~/.graphify/repos/owner/repo(从 URL 中用正则提取 owner/repo);也可以通过--out dir显式指定目标目录,此时dest out_dir。URL 归一化:先去掉尾部/,若 URL 不以.git结尾则自动补上,再从中解析owner/repo;解析失败会报not a recognised GitHub URL并退出,即该命令只接受 GitHub URL。浅克隆:首次克隆使用git clone --depth 1,配合--branch branch可指定分支(分支名以-开头会被判为非法参数,直接报错退出)。重复运行复用克隆:若目标目录已存在,执行git -C dest pull(带分支时为git pull origin -- branch),而不是重新 clone——文档中reuses existing clones on repeat runs的说法由此实现。pull 失败只警告不中断,clone 失败则报错退出。输出提示:完成后打印Ready at: dest并把路径输出,供上层管道消费。多仓库合并:从两个 GitHub 仓库到一张跨仓库图文档给出的多仓库(cross-repo graph)完整流程是:每个仓库各自克隆、各自跑完整 pipeline 产出graph.json,最后合并:# Clone each repo, run the full pipeline on each, then merge graphify clone url1 # → ~/.graphify/repos/owner1/repo1 graphify clone url2 # → ~/.graphify/repos/owner2/repo2 # Run /graphify on each local path to produce their graph.json files # Then merge: graphify merge-graphs \ ~/.graphify/repos/owner1/repo1/graphify-out/graph.json \ ~/.graphify/repos/owner2/repo2/graphify-out/graph.json \ --out graphify-out/cross-repo-graph.json这里的关键约定是:每个仓库的 pipeline 把产物写到该仓库目录内的graphify-out/graph.json,合并输出则可放到任意位置(示例中放在当前目录的graphify-out/cross-repo-graph.json)。文档同时强调:合并图里的每个节点都携带repo属性,可以用来按来源仓库过滤——这一点由merge-graphs的前缀阶段实现(见下文 graphify/build.py#L2005-L2057 中data[repo] repo_tag的赋值)。多个本地子目录合并:为什么必须用 CLI 而不是 skillmonorepo 或 multi-service 布局下,文档特别警告:skill 流水线会把所有中间和最终产物写到当前工作目录下的graphify-out/,如果对各子目录分别跑 skill,会互相覆盖同一个输出目录。正确做法是对每个子目录直接使用 CLI——CLI 会把graphify-out/放在被扫描路径内部:graphify extract ./core/ # → ./core/graphify-out/graph.json graphify extract ./service/ # → ./service/graphify-out/graph.json graphify extract ./platform/ # → ./platform/graphify-out/graph.json # Add --backend gemini|kimi|openai|deepseek|claude-cli depending on which API key you have set # Then merge at the project root: graphify merge-graphs \ ./core/graphify-out/graph.json \ ./service/graphify-out/graph.json \ ./platform/graphify-out/graph.json \ --out graphify-out/graph.json文档还提示,抽取时可根据已配置的 API key 追加--backend gemini|kimi|openai|deepseek|claude-cli。这条路径与 GitHub 场景唯一的区别是输入来源:一个来自~/.graphify/repos/owner/repo,一个来自工作区子目录;合并命令完全一致。merge-graphs 的底层实现:前缀、社区偏移与跨仓库类型连接graphify merge-graphs在 graphify/cli.py#L2454-L2598 中实现,远不只是把两份 JSON 拼起来,它处理了若干合并特有的正确性问题:输入解析与防御性归一化位置参数是至少 2 个graph.json,不足 2 个直接打印用法退出;--out缺省值为graphify-out/merged-graph.json。每个输入都会先做体积上限检查(_enforce_graph_size_cap_or_exit),避免合并超大图。边的键名归一化:新版输出用links,旧版可能写edges,加载前统一改写成links;同时为每条边补上_src/_tgt方向标记,因为在无向node_link_graph中原始方向会被丢失,合并后再恢复回source/target。超边(hyperedges)采用双槽位策略:既保留node_link_graph恢复的graph.hyperedges嵌套槽,也在顶层补一份hyperedges键,保证不同读者都能读到完整集合;合并时逐个收集各输入的前缀化超边,组成并集后重新挂载,避免nx.compose用dict.update覆盖导致只剩最后一个输入的超边。图类型归一化:nx.compose要求所有输入是同一类型。不同来源的graph.json(纯 AST 运行 vs 完整 LLM 运行)可能一个是MultiGraph一个是Graph,甚至有向/无向不一致,_to_simple会统一转成普通无向Graph——从源码注释看,合并后的跨仓库视图本来就是无向的。仓库标签:防止节点 ID 静默碰撞标签生成由 graphify/build.py#L2060 的distinct_repo_tags负责。朴素标签是graphify-out的父目录名,但这不唯一:src/graphify-out和frontend/src/graphify-out都会得到src,若两图都用src::前缀,同名节点(比如后端的src/app.js与前端的App.jsx都以app为干)会被nx.compose静默合并,凭空造出跨运行时的边。因此当标签冲突时,会先加宽为父目录_目录名(如frontend_src),必要时再追加索引后缀,保证每张图一个互不相同的前缀;合并时若发生了标签加宽,会打印note: repo dir names collide; using distinct tags: ...提示。前缀化本身由 graphify/build.py#L2005-L2057 的prefix_graph_for_global完成,行为包括:所有节点 ID 重写为repo_tag::原 ID,label 保持不变(仅用于展示),并写入local_id属性以便还原原始 ID;每个节点设置repo属性——这正是文档所说merged graph carries arepoattribute so you can filter by origin的来源;每条边的_src/_tgt方向标记同步重写到前缀化后的 ID;超边的成员 ID 和超边 ID 本身一起前缀,防止不同仓库同名超边碰撞;社区 ID 偏移:每个输入图都从 0 开始编号社区,若不处理,合并后聚合视图会把无关社区融合成一个元节点。community_offset参数把每张图的社区 ID 平移到共享 ID 空间(第一张偏移为 0,后续依次累计max(community)1),原值保留在local_community属性中。跨仓库共享类型连接:same_type_as 边前缀化让两个仓库都声明的同一契约类型变成两个互不相连的节点。对消息总线式代码库,这恰恰是最值得连接的跳点:一个仓库里 producer 引用SyncProductUpsertToSearchEvent,另一个仓库里 consumer 实现IConsumerSyncProductUpsertToSearchEvent,合并图需要能跨过去。graphify/cross_repo_types.py 的link_shared_type_declarations负责这一步:它把同时具有 namespace、label 和 repo 属性的类型声明按(namespace, label)分组,当组内节点跨越至少两个仓库时,为每对异仓库节点添加一条边,属性为:relationsame_type_as, contextcross_repo, confidenceINFERRED, confidence_score0.9设计上刻意只加边、不合并节点——两个仓库里的契约副本可能已经漂移,折叠成单节点会掩盖这种漂移;而一条same_type_as边既允许遍历跨越仓库边界,又让每侧保留自己的成员、文件与来源信息。模块文档还给出了实际观测:在一对 .NET 服务(1440 与 262 个声明类型)上,namespacename 双匹配只产生 7 对边,全部是共享的EventManager.Models.*Event契约,没有误报。merge-graphs会调用它并在有结果时打印linked N type declaration(s) shared across repos。合并完成后,CLI 通过write_json_atomic原子写出,并打印Merged N graphs - X nodes, Y edges与输出路径。对应的行为验证可参考 tests/test_merge_graphs_cli.py 与 tests/test_cross_repo_shared_types.py。合并之后:graphify query 的快速路径文档最后一段给出了合并图的消费方式:一旦graphify-out/graph.json存在,后续的代码库问题直接对合并图运行graphify query——不再重新抽取,也不再受体积门限(size gate)约束。也就是说,extractmerge-graphs是一次性的建图成本,之后所有查询都在这份静态图上完成;配合节点上的repo属性,查询结果可以按来源仓库筛选,跨仓库的调用/类型关系则通过前缀化 ID 和same_type_as边在图上显式存在。适用前提与注意事项graphify clone只接受 GitHub URL(源码中 URL 正则只匹配github.com),依赖本机git,且首次克隆为--depth 1浅克隆,不保留完整历史;需要特定分支用--branch,需要自定义落点用--out。每个输入图都需独立存在且通过体积上限检查;输入不足 2 个时命令直接报错。对 skill(如 Claude Code 的/graphify)逐子目录跑会写同一个graphify-out/而互相覆盖,本地多目录场景务必用graphify extract dir直接对子目录建图。旧版/新版图的edges/links键差异、超边双槽位、边方向恢复等兼容逻辑都在合并时自动处理,使用者无需手工转换格式。【免费下载链接】graphifyTurn any codebase, with its docs, SQL schemas, configs, and PDFs, into a queryable knowledge graph. A /graphify skill for Claude Code, Cursor, Codex, and Gemini CLI: local deterministic AST parsing, every edge explained, no vector store.项目地址: https://gitcode.com/GitHub_Trending/graph/graphify创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 graphify 实战指南:GitHub 仓库克隆、多子目录图构建与跨仓库图合并
graphify 实战指南:GitHub 仓库克隆、多子目录图构建与跨仓库图合并【免费下载链接】graphifyTurn any codebase, with its docs, SQL schemas, configs, and PDFs, into a queryable knowledge graph. A /graphify skill for Claude Code, Cursor, Codex, and Gemini CLI: local deterministic AST parsing, every edge explained, no vector store.项目地址: https://gitcode.com/GitHub_Trending/graph/graphifygraphify 的 Claude Code skill(graphify/skills/claude/)内置了一套从 GitHub 拉到本地、多仓库/多子目录各自建图、再合并为单一可查询知识图谱的工作流。本文基于 github-and-merge.md 参考文档展开,逐条给出可复制的命令,并结合 graphify/cli.py、graphify/build.py、graphify/cross_repo_types.py 的源码实现,讲清graphify clone与graphify merge-graphs背后的目录约定、节点前缀规则和跨仓库类型连接机制。读完本文,你可以把任意多个 GitHub 仓库或 monorepo 中的多个服务目录,合并成一份带repo属性、可直接用graphify query查询的跨仓库图。适用场景与触发条件根据参考文档开头说明,这份工作流在两种情况下加载:用户传入了一个或多个https://github.com/...URL(需要先把仓库拉到本地);用户指定了多个本地子目录(例如 monorepo 或 multi-service 布局),希望合并成一张图。也就是说,它覆盖远程仓库入口和本地多目录入口两条路径,最终都收敛到同一个动作:用graphify merge-graphs把多份graph.json合并,之后所有代码库问题直接走graphify query查询合并图,无需重新抽取。Step 0:用 graphify clone 克隆 GitHub 仓库文档给出的单仓库用法是:LOCAL_PATH$(graphify clone github-url [--branch branch]) # Use LOCAL_PATH as the target for all subsequent stepsclone子命令把本地路径打印到 stdout(见 cli.py 的 clone 分发逻辑:_clone_repo(...)返回路径后直接print(local_path)),因此可以用命令替换捕获为LOCAL_PATH,后续步骤以它为扫描目标。从源码 graphify/cli.py#L866-L922 的_clone_repo实现看,该命令有几个明确的行为约定:目录约定:默认克隆到~/.graphify/repos/owner/repo(从 URL 中用正则提取 owner/repo);也可以通过--out dir显式指定目标目录,此时dest out_dir。URL 归一化:先去掉尾部/,若 URL 不以.git结尾则自动补上,再从中解析owner/repo;解析失败会报not a recognised GitHub URL并退出,即该命令只接受 GitHub URL。浅克隆:首次克隆使用git clone --depth 1,配合--branch branch可指定分支(分支名以-开头会被判为非法参数,直接报错退出)。重复运行复用克隆:若目标目录已存在,执行git -C dest pull(带分支时为git pull origin -- branch),而不是重新 clone——文档中reuses existing clones on repeat runs的说法由此实现。pull 失败只警告不中断,clone 失败则报错退出。输出提示:完成后打印Ready at: dest并把路径输出,供上层管道消费。多仓库合并:从两个 GitHub 仓库到一张跨仓库图文档给出的多仓库(cross-repo graph)完整流程是:每个仓库各自克隆、各自跑完整 pipeline 产出graph.json,最后合并:# Clone each repo, run the full pipeline on each, then merge graphify clone url1 # → ~/.graphify/repos/owner1/repo1 graphify clone url2 # → ~/.graphify/repos/owner2/repo2 # Run /graphify on each local path to produce their graph.json files # Then merge: graphify merge-graphs \ ~/.graphify/repos/owner1/repo1/graphify-out/graph.json \ ~/.graphify/repos/owner2/repo2/graphify-out/graph.json \ --out graphify-out/cross-repo-graph.json这里的关键约定是:每个仓库的 pipeline 把产物写到该仓库目录内的graphify-out/graph.json,合并输出则可放到任意位置(示例中放在当前目录的graphify-out/cross-repo-graph.json)。文档同时强调:合并图里的每个节点都携带repo属性,可以用来按来源仓库过滤——这一点由merge-graphs的前缀阶段实现(见下文 graphify/build.py#L2005-L2057 中data[repo] repo_tag的赋值)。多个本地子目录合并:为什么必须用 CLI 而不是 skillmonorepo 或 multi-service 布局下,文档特别警告:skill 流水线会把所有中间和最终产物写到当前工作目录下的graphify-out/,如果对各子目录分别跑 skill,会互相覆盖同一个输出目录。正确做法是对每个子目录直接使用 CLI——CLI 会把graphify-out/放在被扫描路径内部:graphify extract ./core/ # → ./core/graphify-out/graph.json graphify extract ./service/ # → ./service/graphify-out/graph.json graphify extract ./platform/ # → ./platform/graphify-out/graph.json # Add --backend gemini|kimi|openai|deepseek|claude-cli depending on which API key you have set # Then merge at the project root: graphify merge-graphs \ ./core/graphify-out/graph.json \ ./service/graphify-out/graph.json \ ./platform/graphify-out/graph.json \ --out graphify-out/graph.json文档还提示,抽取时可根据已配置的 API key 追加--backend gemini|kimi|openai|deepseek|claude-cli。这条路径与 GitHub 场景唯一的区别是输入来源:一个来自~/.graphify/repos/owner/repo,一个来自工作区子目录;合并命令完全一致。merge-graphs 的底层实现:前缀、社区偏移与跨仓库类型连接graphify merge-graphs在 graphify/cli.py#L2454-L2598 中实现,远不只是把两份 JSON 拼起来,它处理了若干合并特有的正确性问题:输入解析与防御性归一化位置参数是至少 2 个graph.json,不足 2 个直接打印用法退出;--out缺省值为graphify-out/merged-graph.json。每个输入都会先做体积上限检查(_enforce_graph_size_cap_or_exit),避免合并超大图。边的键名归一化:新版输出用links,旧版可能写edges,加载前统一改写成links;同时为每条边补上_src/_tgt方向标记,因为在无向node_link_graph中原始方向会被丢失,合并后再恢复回source/target。超边(hyperedges)采用双槽位策略:既保留node_link_graph恢复的graph.hyperedges嵌套槽,也在顶层补一份hyperedges键,保证不同读者都能读到完整集合;合并时逐个收集各输入的前缀化超边,组成并集后重新挂载,避免nx.compose用dict.update覆盖导致只剩最后一个输入的超边。图类型归一化:nx.compose要求所有输入是同一类型。不同来源的graph.json(纯 AST 运行 vs 完整 LLM 运行)可能一个是MultiGraph一个是Graph,甚至有向/无向不一致,_to_simple会统一转成普通无向Graph——从源码注释看,合并后的跨仓库视图本来就是无向的。仓库标签:防止节点 ID 静默碰撞标签生成由 graphify/build.py#L2060 的distinct_repo_tags负责。朴素标签是graphify-out的父目录名,但这不唯一:src/graphify-out和frontend/src/graphify-out都会得到src,若两图都用src::前缀,同名节点(比如后端的src/app.js与前端的App.jsx都以app为干)会被nx.compose静默合并,凭空造出跨运行时的边。因此当标签冲突时,会先加宽为父目录_目录名(如frontend_src),必要时再追加索引后缀,保证每张图一个互不相同的前缀;合并时若发生了标签加宽,会打印note: repo dir names collide; using distinct tags: ...提示。前缀化本身由 graphify/build.py#L2005-L2057 的prefix_graph_for_global完成,行为包括:所有节点 ID 重写为repo_tag::原 ID,label 保持不变(仅用于展示),并写入local_id属性以便还原原始 ID;每个节点设置repo属性——这正是文档所说merged graph carries arepoattribute so you can filter by origin的来源;每条边的_src/_tgt方向标记同步重写到前缀化后的 ID;超边的成员 ID 和超边 ID 本身一起前缀,防止不同仓库同名超边碰撞;社区 ID 偏移:每个输入图都从 0 开始编号社区,若不处理,合并后聚合视图会把无关社区融合成一个元节点。community_offset参数把每张图的社区 ID 平移到共享 ID 空间(第一张偏移为 0,后续依次累计max(community)1),原值保留在local_community属性中。跨仓库共享类型连接:same_type_as 边前缀化让两个仓库都声明的同一契约类型变成两个互不相连的节点。对消息总线式代码库,这恰恰是最值得连接的跳点:一个仓库里 producer 引用SyncProductUpsertToSearchEvent,另一个仓库里 consumer 实现IConsumerSyncProductUpsertToSearchEvent,合并图需要能跨过去。graphify/cross_repo_types.py 的link_shared_type_declarations负责这一步:它把同时具有 namespace、label 和 repo 属性的类型声明按(namespace, label)分组,当组内节点跨越至少两个仓库时,为每对异仓库节点添加一条边,属性为:relationsame_type_as, contextcross_repo, confidenceINFERRED, confidence_score0.9设计上刻意只加边、不合并节点——两个仓库里的契约副本可能已经漂移,折叠成单节点会掩盖这种漂移;而一条same_type_as边既允许遍历跨越仓库边界,又让每侧保留自己的成员、文件与来源信息。模块文档还给出了实际观测:在一对 .NET 服务(1440 与 262 个声明类型)上,namespacename 双匹配只产生 7 对边,全部是共享的EventManager.Models.*Event契约,没有误报。merge-graphs会调用它并在有结果时打印linked N type declaration(s) shared across repos。合并完成后,CLI 通过write_json_atomic原子写出,并打印Merged N graphs - X nodes, Y edges与输出路径。对应的行为验证可参考 tests/test_merge_graphs_cli.py 与 tests/test_cross_repo_shared_types.py。合并之后:graphify query 的快速路径文档最后一段给出了合并图的消费方式:一旦graphify-out/graph.json存在,后续的代码库问题直接对合并图运行graphify query——不再重新抽取,也不再受体积门限(size gate)约束。也就是说,extractmerge-graphs是一次性的建图成本,之后所有查询都在这份静态图上完成;配合节点上的repo属性,查询结果可以按来源仓库筛选,跨仓库的调用/类型关系则通过前缀化 ID 和same_type_as边在图上显式存在。适用前提与注意事项graphify clone只接受 GitHub URL(源码中 URL 正则只匹配github.com),依赖本机git,且首次克隆为--depth 1浅克隆,不保留完整历史;需要特定分支用--branch,需要自定义落点用--out。每个输入图都需独立存在且通过体积上限检查;输入不足 2 个时命令直接报错。对 skill(如 Claude Code 的/graphify)逐子目录跑会写同一个graphify-out/而互相覆盖,本地多目录场景务必用graphify extract dir直接对子目录建图。旧版/新版图的edges/links键差异、超边双槽位、边方向恢复等兼容逻辑都在合并时自动处理,使用者无需手工转换格式。【免费下载链接】graphifyTurn any codebase, with its docs, SQL schemas, configs, and PDFs, into a queryable knowledge graph. A /graphify skill for Claude Code, Cursor, Codex, and Gemini CLI: local deterministic AST parsing, every edge explained, no vector store.项目地址: https://gitcode.com/GitHub_Trending/graph/graphify创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考