GitNexus索引存储结构揭秘.gitnexus和~/.gitnexus里都有什么【免费下载链接】GitNexusGitNexus: The Zero-Server Code Intelligence Engine - GitNexus is a client-side knowledge graph creator that runs entirely in your browser. Drop in a git repository (Github, Gitlab, Azure, Local) or ZIP file, and get an interactive knowledge graph with a built in Graph RAG Agent. Perfect for code exploration项目地址: https://gitcode.com/GitHub_Trending/gi/GitNexusGitNexus 是一个客户端代码智能引擎把代码仓库解析成可交互的知识图谱并内置 Graph RAG Agent。但很多新手都有同一个疑问GitNexus 的索引到底存在哪里.gitnexus和~/.gitnexus这两个目录里到底藏了什么本文带你完整拆解 GitNexus 索引存储结构从仓库内的元数据文件、图数据库、解析缓存到全局注册表一次讲清楚。️ 先搞懂两级目录的分工GitNexus 的存储设计遵循就近原则分为两级位置作用是否随仓库走仓库/.gitnexus/单个仓库的索引、元数据、解析缓存✅ 跟着仓库但被 git 忽略~/.gitnexus/全局注册表、CLI 配置、仓库组、克隆目录❌ 全局共享一句话记忆.gitnexus存这个仓库分析出了什么~/.gitnexus存这台机器上有哪些仓库被 GitNexus 管着。仓库内的.gitnexus目录由存储管理层统一管理核心逻辑见 repo-manager.ts目录常量定义在 repo-meta.ts。GitNexus 会自动写入.gitignore确保索引目录不会污染你的git status。.gitnexus/目录里都有什么1️⃣gitnexus.json—— 索引的户口本这是每个被分析仓库的元数据文件记录着本次索引的体检报告repoPath / lastCommit / indexedAt仓库路径、索引时的提交、索引时间stats文件数、节点数、边数、社区数、嵌入向量数capabilities图查询、全文搜索FTS、向量搜索各自是否可用schemaFingerprint图结构的指纹版本升级时自动判断是否需要重建索引元数据的完整结构定义在 repo-meta.ts。 小知识这个文件早年叫meta.json后来改名为gitnexus.json。为保证兼容GitNexus 会双写两个文件老版本读meta.json也不会出问题。2️⃣lbug—— 代码知识图谱数据库这是整个索引的心脏。GitNexus 把代码解析后写入一个嵌入式图数据库LadybugDB由早期 KuzuDB 迁移而来符号、函数调用、导入关系、路由表都变成图中的节点和边供后续的影响分析、路径查询使用。数据库文件旁边可能还有几个伴生文件lbug.wal预写日志保证写入不丢数据lbug.lock/lbug.init.lock进程间锁防止两个 GitNexus 同时读写数据库适配逻辑见 lbug-adapter.ts。如果你升级过 GitNexusclean命令会自动清理残留的旧kuzu数据库文件相关逻辑在 repo-manager.ts。3️⃣parse-cache/与parsedfile-store/—— 秒开的关键第二次分析时 GitNexus 为何比第一次快得多全靠这两个缓存目录parse-cache/按代码块chunk内容哈希命名的分片缓存文件没变就直接复用解析结果索引结构定义在 parse-cache.tsparsedfile-store/与parsedfile-cache/完整解析产物的分片存储前者每次分析重写、后者跨运行持久保存见 parsedfile-store.ts这两个缓存跨分支共享放在.gitnexus根下而非分支子目录所以多分支切换时增量分析尤其快。4️⃣branches/—— 多分支独立索引分析非主分支时GitNexus 不会覆盖主分支索引而是在branches/分支名/下建立独立槽位各自拥有自己的lbug数据库和gitnexus.json.gitnexus/ ├── gitnexus.json # 主分支扁平槽位元数据 ├── lbug # 主分支图数据库 ├── parse-cache/ # 跨分支共享的解析缓存 ├── parsedfile-store/ ├── branches/ │ └── feature-xxx/ │ ├── gitnexus.json # 分支专属元数据 │ └── lbug # 分支专属图数据库 └── wiki/ # 生成的代码 Wiki可选分支槽位的分配逻辑在 branch-index.ts。5️⃣wiki/—— 一键生成的代码 Wiki运行 Wiki 命令后GitNexus 会在.gitnexus/wiki/下输出index.html和module_tree.json是一份可以直接在浏览器打开的仓库模块导航生成逻辑见 wiki.ts。~/.gitnexus/全局目录里都有什么全局目录路径可通过环境变量GITNEXUS_HOME覆盖Docker 部署就会用到默认即用户主目录下的.gitnexus。registry.json—— 全局仓库注册表这是 MCP 服务器和gitnexus list发现已索引仓库的核心文件。每条记录包含仓库名、路径、存储路径、索引时间、远程地址以及分支信息。注册表条目结构定义在 repo-manager.ts读写逻辑集中在 repo-manager.ts。⚠️ 注意registry.json是明文 JSON手动编辑后可能出现仓库在注册表里但磁盘路径对不上的情况。此时gitnexus doctor会给出明确提示指引你删除错误条目或重新analyze。config.json—— CLI 全局配置保存 LLM API 密钥等 CLI 级配置例如 Wiki 生成用的 API key 就存在这里读写逻辑见 repo-manager.ts。repos/与uploads/—— 服务端暂存区repos/仓库名/通过服务端克隆远程仓库时的落地目录路径定义在 git-clone.tsuploads/浏览器端上传 ZIP 包分析时的暂存区路径定义在 upload-paths.tsgroups/—— 跨仓库组配置想做跨仓库的影响分析比如前端 后端一起分析GitNexus 提供仓库组每个组是groups/下的一个目录核心是一个group.yaml声明成员仓库解析逻辑见 storage.ts。配置好后即可用gitnexus group impact 组名做跨库追踪。 索引存储的日常检查与清理命令用途gitnexus status查看仓库索引状态、新鲜度gitnexus list列出注册表中所有已索引仓库gitnexus doctor诊断存储与搜索索引的可用性问题gitnexus clean清理指定仓库或指定分支的本地索引gitnexus remove 名称从registry.json中注销仓库doctor的存储自检逻辑见 doctor.ts清理命令的实现见 clean.ts。 这些文件最终如何被 AI 使用索引存储的最终消费者是 AI 编程助手。GitNexus 通过 MCP 协议向 AI 暴露impact影响分析、query图查询、context上下文等工具底层读取的正是.gitnexus/lbug图数据库和registry.json中登记的仓库。在支持 MCP 的编辑器里启用 GitNexus 后AI 回答改这个函数会影响哪里时答案全部来自这份本地索引——不上传、不过服务器。更多 MCP 用法可参考项目内文档 kilo-code-mcp.md。✅ 总结.gitnexus/仓库内gitnexus.json元数据 lbug图数据库 parse-cache等解析缓存 branches/多分支槽位 wiki/产出全部被 git 忽略~/.gitnexus/全局registry.json仓库注册表 config.jsonCLI 配置 repos/、uploads/服务端暂存 groups/跨仓库组索引心脏是lbug图数据库秒开靠parse-cacheAI 消费靠 MCP理解这套 GitNexus 索引存储结构后你就能从容地判断何时需要重新analyze、磁盘占用去了哪里以及多分支、多仓库场景下如何管理索引。【免费下载链接】GitNexusGitNexus: The Zero-Server Code Intelligence Engine - GitNexus is a client-side knowledge graph creator that runs entirely in your browser. Drop in a git repository (Github, Gitlab, Azure, Local) or ZIP file, and get an interactive knowledge graph with a built in Graph RAG Agent. Perfect for code exploration项目地址: https://gitcode.com/GitHub_Trending/gi/GitNexus创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 GitNexus索引存储结构揭秘：.gitnexus和~/.gitnexus里都有什么
GitNexus索引存储结构揭秘.gitnexus和~/.gitnexus里都有什么【免费下载链接】GitNexusGitNexus: The Zero-Server Code Intelligence Engine - GitNexus is a client-side knowledge graph creator that runs entirely in your browser. Drop in a git repository (Github, Gitlab, Azure, Local) or ZIP file, and get an interactive knowledge graph with a built in Graph RAG Agent. Perfect for code exploration项目地址: https://gitcode.com/GitHub_Trending/gi/GitNexusGitNexus 是一个客户端代码智能引擎把代码仓库解析成可交互的知识图谱并内置 Graph RAG Agent。但很多新手都有同一个疑问GitNexus 的索引到底存在哪里.gitnexus和~/.gitnexus这两个目录里到底藏了什么本文带你完整拆解 GitNexus 索引存储结构从仓库内的元数据文件、图数据库、解析缓存到全局注册表一次讲清楚。️ 先搞懂两级目录的分工GitNexus 的存储设计遵循就近原则分为两级位置作用是否随仓库走仓库/.gitnexus/单个仓库的索引、元数据、解析缓存✅ 跟着仓库但被 git 忽略~/.gitnexus/全局注册表、CLI 配置、仓库组、克隆目录❌ 全局共享一句话记忆.gitnexus存这个仓库分析出了什么~/.gitnexus存这台机器上有哪些仓库被 GitNexus 管着。仓库内的.gitnexus目录由存储管理层统一管理核心逻辑见 repo-manager.ts目录常量定义在 repo-meta.ts。GitNexus 会自动写入.gitignore确保索引目录不会污染你的git status。.gitnexus/目录里都有什么1️⃣gitnexus.json—— 索引的户口本这是每个被分析仓库的元数据文件记录着本次索引的体检报告repoPath / lastCommit / indexedAt仓库路径、索引时的提交、索引时间stats文件数、节点数、边数、社区数、嵌入向量数capabilities图查询、全文搜索FTS、向量搜索各自是否可用schemaFingerprint图结构的指纹版本升级时自动判断是否需要重建索引元数据的完整结构定义在 repo-meta.ts。 小知识这个文件早年叫meta.json后来改名为gitnexus.json。为保证兼容GitNexus 会双写两个文件老版本读meta.json也不会出问题。2️⃣lbug—— 代码知识图谱数据库这是整个索引的心脏。GitNexus 把代码解析后写入一个嵌入式图数据库LadybugDB由早期 KuzuDB 迁移而来符号、函数调用、导入关系、路由表都变成图中的节点和边供后续的影响分析、路径查询使用。数据库文件旁边可能还有几个伴生文件lbug.wal预写日志保证写入不丢数据lbug.lock/lbug.init.lock进程间锁防止两个 GitNexus 同时读写数据库适配逻辑见 lbug-adapter.ts。如果你升级过 GitNexusclean命令会自动清理残留的旧kuzu数据库文件相关逻辑在 repo-manager.ts。3️⃣parse-cache/与parsedfile-store/—— 秒开的关键第二次分析时 GitNexus 为何比第一次快得多全靠这两个缓存目录parse-cache/按代码块chunk内容哈希命名的分片缓存文件没变就直接复用解析结果索引结构定义在 parse-cache.tsparsedfile-store/与parsedfile-cache/完整解析产物的分片存储前者每次分析重写、后者跨运行持久保存见 parsedfile-store.ts这两个缓存跨分支共享放在.gitnexus根下而非分支子目录所以多分支切换时增量分析尤其快。4️⃣branches/—— 多分支独立索引分析非主分支时GitNexus 不会覆盖主分支索引而是在branches/分支名/下建立独立槽位各自拥有自己的lbug数据库和gitnexus.json.gitnexus/ ├── gitnexus.json # 主分支扁平槽位元数据 ├── lbug # 主分支图数据库 ├── parse-cache/ # 跨分支共享的解析缓存 ├── parsedfile-store/ ├── branches/ │ └── feature-xxx/ │ ├── gitnexus.json # 分支专属元数据 │ └── lbug # 分支专属图数据库 └── wiki/ # 生成的代码 Wiki可选分支槽位的分配逻辑在 branch-index.ts。5️⃣wiki/—— 一键生成的代码 Wiki运行 Wiki 命令后GitNexus 会在.gitnexus/wiki/下输出index.html和module_tree.json是一份可以直接在浏览器打开的仓库模块导航生成逻辑见 wiki.ts。~/.gitnexus/全局目录里都有什么全局目录路径可通过环境变量GITNEXUS_HOME覆盖Docker 部署就会用到默认即用户主目录下的.gitnexus。registry.json—— 全局仓库注册表这是 MCP 服务器和gitnexus list发现已索引仓库的核心文件。每条记录包含仓库名、路径、存储路径、索引时间、远程地址以及分支信息。注册表条目结构定义在 repo-manager.ts读写逻辑集中在 repo-manager.ts。⚠️ 注意registry.json是明文 JSON手动编辑后可能出现仓库在注册表里但磁盘路径对不上的情况。此时gitnexus doctor会给出明确提示指引你删除错误条目或重新analyze。config.json—— CLI 全局配置保存 LLM API 密钥等 CLI 级配置例如 Wiki 生成用的 API key 就存在这里读写逻辑见 repo-manager.ts。repos/与uploads/—— 服务端暂存区repos/仓库名/通过服务端克隆远程仓库时的落地目录路径定义在 git-clone.tsuploads/浏览器端上传 ZIP 包分析时的暂存区路径定义在 upload-paths.tsgroups/—— 跨仓库组配置想做跨仓库的影响分析比如前端 后端一起分析GitNexus 提供仓库组每个组是groups/下的一个目录核心是一个group.yaml声明成员仓库解析逻辑见 storage.ts。配置好后即可用gitnexus group impact 组名做跨库追踪。 索引存储的日常检查与清理命令用途gitnexus status查看仓库索引状态、新鲜度gitnexus list列出注册表中所有已索引仓库gitnexus doctor诊断存储与搜索索引的可用性问题gitnexus clean清理指定仓库或指定分支的本地索引gitnexus remove 名称从registry.json中注销仓库doctor的存储自检逻辑见 doctor.ts清理命令的实现见 clean.ts。 这些文件最终如何被 AI 使用索引存储的最终消费者是 AI 编程助手。GitNexus 通过 MCP 协议向 AI 暴露impact影响分析、query图查询、context上下文等工具底层读取的正是.gitnexus/lbug图数据库和registry.json中登记的仓库。在支持 MCP 的编辑器里启用 GitNexus 后AI 回答改这个函数会影响哪里时答案全部来自这份本地索引——不上传、不过服务器。更多 MCP 用法可参考项目内文档 kilo-code-mcp.md。✅ 总结.gitnexus/仓库内gitnexus.json元数据 lbug图数据库 parse-cache等解析缓存 branches/多分支槽位 wiki/产出全部被 git 忽略~/.gitnexus/全局registry.json仓库注册表 config.jsonCLI 配置 repos/、uploads/服务端暂存 groups/跨仓库组索引心脏是lbug图数据库秒开靠parse-cacheAI 消费靠 MCP理解这套 GitNexus 索引存储结构后你就能从容地判断何时需要重新analyze、磁盘占用去了哪里以及多分支、多仓库场景下如何管理索引。【免费下载链接】GitNexusGitNexus: The Zero-Server Code Intelligence Engine - GitNexus is a client-side knowledge graph creator that runs entirely in your browser. Drop in a git repository (Github, Gitlab, Azure, Local) or ZIP file, and get an interactive knowledge graph with a built in Graph RAG Agent. Perfect for code exploration项目地址: https://gitcode.com/GitHub_Trending/gi/GitNexus创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考