ghcr.io/abhigyanpatwari/gitnexus-web:1.6.8-rc.56

GitNexus

[!IMPORTANT]
GitNexus 没有官方加密货币、或硬币。任何在 Pump.fun 或其他平台使用 GitNexus 名称的/硬币均与本项目或其维护者无关联、未获认可且非本项目创建。请勿购买任何声称与 GitNexus 相关的加密货币。

加入官方 *** 讨论想法、问题等！

企业版（SaaS 及自托管）- akonlabs.com

为智能体上下文构建神经系统。

将任何代码库索引为知识图谱——包含所有依赖、调用链、集群和执行流——然后通过智能工具暴露出来，确保 AI 智能体不会遗漏任何代码。

类似 DeepWiki，但更深入。 DeepWiki 帮助你_理解_代码，而 GitNexus 让你_分析_代码——因为知识图谱会追踪每一处关系，而不仅仅是描述。

简而言之： Web UI 是与任何仓库快速对话的方式。CLI + MCP 则让你的 AI 智能体真正可靠——它为 Cursor、Claude Code、Antigravity、Codex 等工具提供代码库的深入架构视图，避免它们遗漏依赖、破坏调用链和盲目提交修改。即使是小型模型也能获得完整的架构清晰度，从而可与大型模型竞争。

---

星级历史

使用 GitNexus 的两种方式

桥接模式： gitnexus serve 可连接两者——Web UI 会自动检测本地服务器，无需重新上传或重新索引即可浏览所有通过 CLI 索引的仓库。

---

企业版

GitNexus 提供企业级产品——既可作为完全托管的SaaS，也可自托管部署。开源版本也可通过适当授权进行商业使用。

企业版包含：

• PR 审查 - 拉取请求的自动影响范围分析
• 自动更新的代码维基 - 始终保持最新的文档（代码维基在开源版本中也可用）
• 自动重新索引 - 知识图谱自动保持最新
• 多仓库支持 - 跨仓库的统一图谱
• OCaml 语言支持 - 额外的语言覆盖
• 优先功能/语言支持 - 可请求新语言或功能

即将推出：

• 自动回归分析
• 端到端测试生成

👉 访问akonlabs.com了解更多

💬 商业许可或企业咨询，请通过***联系我们，或发送邮件至 ***

---

开发

• ARCHITECTURE.md — 包结构、索引→图谱→MCP 流程、代码修改位置
• RUNBOOK.md — 分析、嵌入、索引过期、MCP 恢复、CI 代码片段
• GUARDRAILS.md — 贡献者和智能体的安全规则与操作“信号”
• CONTRIBUTING.md — 许可、设置、提交和拉取请求
• TESTING.md — gitnexus 和 gitnexus-web 的测试命令

CLI + MCP（推荐）

CLI 会索引您的仓库并运行 MCP 服务器，为 AI 智能体提供深入的代码库感知能力。

快速开始

# 索引您的仓库（从仓库根目录运行）
npx gitnexus analyze

就是这样。此命令会索引代码库、安装智能体技能、注册 Claude Code 钩子，并创建 AGENTS.md/CLAUDE.md 上下文文件——所有操作一步完成。

使用 npm 11.x？ npx 可能在安装时崩溃并显示 Cannot destructure property 'package' of 'node.target'（这是 npm/arborist 的 bug，在 GitNexus 运行前发生）。请改用 pnpm——它会显式构建原生依赖：

> pnpm --allow-build=@ladybugdb/core --allow-build=gitnexus --allow-build=tree-sitter dlx gitnexus@latest analyze
>

或者全局安装（npm install -g gitnexus@latest）并运行 gitnexus analyze。参见https://github.com/abhigyanpatwari/GitNexus/issues/1939%E3%80%82

要为编辑器配置 MCP，运行一次 npx gitnexus setup——或按以下步骤手动设置。

更快安装（无需 C++ 工具链）： 在 npm install -g gitnexus 前设置 GITNEXUS_SKIP_OPTIONAL_GRAMMARS=1，可跳过 tree-sitter-dart、tree-sitter-proto、tree-sitter-swift 和 tree-sitter-kotlin 的 vendored 语法构建——这四种语言将无法解析，但安装可在几秒钟内完成，无需 python3/make/g++。仅严格支持 =1——任何其他值都会触发重新构建。参见下方 tree-sitter-kotlin 说明。

关于 tree-sitter-kotlin： 与 Dart/Proto/Swift 类似，Kotlin 是一种vendored语法（位于 gitnexus/vendor/tree-sitter-kotlin）。上游 tree-sitter-kotlin 仅提供源代码（无预构建二进制文件），因此 GitNexus 会自行构建 Kotlin 平台预构建文件（通过 build-tree-sitter-prebuilds GitHub Actions 工作流）并进行 vendored——这与 Dart、Proto 和 Swift 使用的统一流程相同（Swift 的预构建文件最初从上游复制，现在也由 GitNexus 跨平台构建）。node-gyp-build 会在引入时选择正确的 .node 文件，因此无需 C/C++ 工具链。如果没有与您的平台架构匹配的预构建文件，仅 Kotlin（.kt/.kts）解析不可用；gitnexus 的其他功能不受影响。

MCP 设置

gitnexus setup 会自动检测您的编辑器并写入正确的全局 MCP 配置。只需运行一次即可。要仅配置选定的集成，可使用 --coding-agent/-c 参数并传入逗号分隔的列表，或重复该选项，例如 gitnexus setup -c cursor,codex。

编辑器支持

¹ Antigravity 钩子遵循 Gemini CLI 钩子参考文档（Antigravity 2.0 是 Gemini CLI 的官方继任版本）。增强操作在 AfterTool 阶段运行，因为在 Gemini 协议中 BeforeTool 没有上下文注入通道——代理通过 hookSpecificOutput.additionalContext 看到附加到工具结果的图谱上下文。成功执行 git commit/merge/rebase/cherry-pick/pull 后，过时索引提示会进入同一通道。如果 Antigravity 特定的钩子文档与 Gemini CLI 的文档出现差异，架构可能会演进；实现将跟踪这些变化。

环境变量

大多数 analyze 控制选项同时也是 CLI 标志（--workers、--worker-timeout、--max-file-size、--verbose）。当需要在每次运行时重复使用相同标志，或从已管理自身环境的长期运行主机（MCP server、eval-server、CI shell）调用 GitNexus 时，使用环境变量形式。CLI 标志优先于环境变量；环境变量优先于内置默认值。

发布到understand-quickly（可选）

https://github.com/looptech-ai/understand-quickly 是一个公共代码知识图谱 registry，将 gitnexus@1 列为一等格式。注册仓库一次后（npx @understand-quickly/cli add 或 https://looptech-ai.github.io/understand-quickly/add.html%EF%BC%89%EF%BC%8C%60gitnexus publish会触发单个repository_dispatch` 事件，使 registry 按需重新同步你的条目，而非等待夜间任务。

这是可选功能，若未设置 UNDERSTAND_QUICKLY_TOKEN 则不执行任何操作——该 token 是在 registry 仓库上具有 Repository dispatches: write 权限的细粒度 GitHub PAT。不会上传任何图谱文件。完整协议参见 https://github.com/looptech-ai/understand-quickly/blob/main/docs/integrations/protocol.md%E3%80%82

你的AI代理将获得什么

通过MCP公开的16个工具（11个每仓库工具 + 5个组工具）：

Docker

官方 Docker 安装包提供由 docker-compose.yaml 编排的两个签名镜像。每个镜像均发布至 GitHub Container Registry (GHCR) 和 Docker Hub —— 相同构建、相同摘要、相同 Cosign 签名 —— 因此可选择任意偏好的 registry：

[!NOTE] 镜像重命名提示。 早期版本的 Web UI 发布在 ghcr.io/abhigyanpatwari/gitnexus 下。随着捆绑后端的引入，该地址现在托管 CLI/服务器镜像，而 UI 已迁移至 ghcr.io/abhigyanpatwari/gitnexus-web。旧标签仍可用于拉取，但新版本仅在新地址发布。请相应更新您的 docker run / compose 文件（或直接采用捆绑的 compose）。

一键设置

docker compose up -d

这会在 http://localhost:4747 启动服务器，在 http://localhost:4173 启动 Web UI。UI 会自动检测服务器，因为浏览器运行在主机上，并通过映射端口访问容器。

命名卷（gitnexus-data）会将全局注册表、索引和克隆的仓库持久化到服务器容器内的 /data/gitnexus 目录。要使主机上的仓库可被索引，请在启动堆栈前设置 WORKSPACE_DIR：

WORKSPACE_DIR=$HOME/code docker compose up -d
# 在服务器容器内，该目录以只读方式挂载在/workspace。
docker compose exec gitnexus-server gitnexus index /workspace/my-repo

直接使用 docker run

# 服务器
docker run --rm -d \
--name gitnexus-server \
-p 4747:4747 \
-v gitnexus-data:/data/gitnexus \
ghcr.io/abhigyanpatwari/gitnexus:latest

# Web UI
docker run --rm -d \
--name gitnexus-web \
-p 4173:4173 \
ghcr.io/abhigyanpatwari/gitnexus-web:latest

可选的环境变量文件（覆盖镜像标签、容器名称、端口、工作区目录）：

cp .env.example .env
docker compose --env-file .env up -d

版本控制与供应链保护

Docker 镜像与 npm 包版本锁定：

• 稳定镜像仅从 vX.Y.Z git 标签发布（通过 docker.yml 工作流由标签推送直接触发），且工作流会验证标签是否与 gitnexus/package.json 的版本完全匹配，否则拒绝构建。因此 ghcr.io/abhigyanpatwari/gitnexus:1.6.2（及其 Docker Hub 镜像 akonlabs/gitnexus:1.6.2）与 npm install gitnexus@1.6.2 是字节级一致的版本——无漂移，无来自 main 分支的浮动构建。两个镜像仓库从同一构建步骤获得相同的摘要，因此可从任一仓库拉取，签名验证结果完全一致。
• 候选发布镜像（如 :1.7.0-rc.1）与每个 RC 版本的 npm 包一同发布。它们由 publish.yml 在 RC 标签创建并推送后，调用 docker.yml 作为可重用工作流构建。
• :latest 标签仅由 Docker 元数据操作从非预发布标签自动提升，因此始终指向真实的、已发布到 npm 的版本。

两个镜像均使用工作流的 GitHub OIDC 身份通过 https://docs.sigstore.dev/cosign/signing/overview/ 进行签名，并附带构建来源证明和 SBOM 证明。这是您抵御供应链的保护措施**：即使**者在其他地方重新发布同名镜像（或通过某种方式推送到拼写相似的仓库），也无法伪造与 abhigyanpatwari/GitNexus 的 docker.yml 绑定的 Cosign 签名。在敏感环境中拉取镜像前务必验证：

稳定版本——从 v* 标签引用签名：

cosign verify ghcr.io/abhigyanpatwari/gitnexus:1.6.2 \
--certificate-identity-regexp '^https://github\.com/abhigyanpatwari/GitNexus/\.github/workflows/docker\.yml@refs/tags/v[0-9]+\.[0-9]+\.[0-9]+(-[a-zA-Z0-9.]+)?

正则表达式将证书身份固定到本仓库的 `docker.yml` 工作流**从 `v*` 标签运行**——拒绝未签名镜像、由其他工作流签名的镜像以及从未受保护引用签名的镜像。两个仓库的验证规则相同，因为两组标签在同一工作流运行中以相同摘要签名。

**候选发布版本**——从 `refs/heads/main` 签名（`publish.yml` 调用 `docker.yml` 作为可重用工作流时的调用者引用）：
```bash
cosign verify ghcr.io/abhigyanpatwari/gitnexus:1.7.0-rc.1 \
--certificate-identity 'https://github.com/abhigyanpatwari/GitNexus/.github/workflows/docker.yml@refs/heads/main' \
--certificate-oidc-issuer [***]

您还可以检查构建来源证明和 SBOM：

cosign download attestation ghcr.io/abhigyanpatwari/gitnexus:1.6.2 \
--predicate-type https://slsa.dev/provenance/v1

Kubernetes：在准入阶段强制签名验证

对于 Kubernetes 部署，部署捆绑的 ClusterImagePolicy，以便 https://docs.sigstore.dev/policy-controller/overview/ 拒绝任何未由本仓库 docker.yml 从 vX.Y.Z 标签运行签名的 GitNexus 镜像——与上述 cosign verify 片段固定的身份相同。

# 1. 安装控制器（一次性，集群范围）
helm repo add sigstore https://sigstore.github.io/helm-charts && helm repo update
helm install policy-controller -n cosign-system --create-namespace \
sigstore/policy-controller

# 2. 标记命名空间为启用
kubectl label namespace policy.sigstore.dev/include=true

# 3. 应用策略
kubectl apply -f deploy/kubernetes/cluster-image-policy.yaml

完成后，尝试部署未签名镜像——或由 abhigyanpatwari/GitNexus 的 docker.yml 从非 v* 标签签名的镜像——将在 Pod 创建前被准入 Webhook 拒绝。这会将可验证的签名转换为强制策略，这是大多数集群实际需要的供应链控制措施。

文件

• Dockerfile.web — 构建 gitnexus-shared 和 gitnexus-web，然后提供生产环境前端服务。
• Dockerfile.cli — 构建 CLI/服务器（包含原生依赖）并运行 gitnexus serve --host 0.0.0.0。
• docker-compose.yaml — 同时启动两个已签名镜像。
• .env.example — 用于覆盖镜像名称、容器名称、端口和工作区挂载的配置。

Web UI 使用与 CLI 相同的索引管道，但完全在 WebAssembly 中运行（Tree-sitter WASM、LadybugDB WASM、浏览器内嵌入）。它适用于快速探索，但对于较大的仓库会受浏览器内存限制。

本地后端模式：运行 gitnexus serve 并在本地打开 Web UI——它会自动检测服务器并显示所有已索引的仓库，支持完整的 AI 聊天功能。无需重新上传或重新索引。智能体工具（Cypher 查询、搜索、代码导航）会自动通过后端 HTTP API 路由。

---

GitNexus 解决的问题

像 Cursor、Claude Code、Codex、Cline、Roo Code 和 Windsurf 这样的工具功能强大——但它们并不真正了解您的代码库结构。

实际情况：

1. AI 编辑 UserService.validate()
2. 不知道有 47 个函数依赖于其返回类型
3. 破坏性变更被发布

传统 Graph RAG 与 GitNexus

传统方法向 LLM 提供原始图边缘，并希望它进行足够的探索。GitNexus 在索引时预先计算结构——聚类、追踪、评分——因此工具可在一次调用中返回完整上下文：

flowchart TB
subgraph Traditional["传统 Graph RAG"]
direction TB
U1["用户：哪些依赖 UserService？"]
U1 --> LLM1["LLM 接收原始图"]
LLM1 --> Q1["查询 1：查找调用者"]
Q1 --> Q2["查询 2：哪些文件？"]
Q2 --> Q3["查询 3：过滤测试？"]
Q3 --> Q4["查询 4：高风险？"]
Q4 --> OUT1["4 次以上查询后得到答案"]
end

--certificate-oidc-issuer https://token.actions.githubusercontent.com

相同的签名可验证 Docker Hub 镜像（摘要相同）：

cosign verify docker.io/akonlabs/gitnexus:1.6.2
--certificate-identity-regexp '^https://github\.com/abhigyanpatwari/GitNexus/\.github/workflows/docker\.yml@refs/tags/v[0-9]+\.[0-9]+\.[0-9]+(-[a-zA-Z0-9.]+)?

正则表达式将证书身份固定到本仓库的 CODE_TOKEN_163 工作流从 CODE_TOKEN_164 标签运行——拒绝未签名镜像、由其他工作流签名的镜像以及从未受保护引用签名的镜像。两个仓库的验证规则相同，因为两组标签在同一工作流运行中以相同摘要签名。

候选发布版本——从 CODE_TOKEN_165 签名（CODE_TOKEN_166 调用 CODE_TOKEN_167 作为可重用工作流时的调用者引用）：

CODE_TOKEN_7

您还可以检查构建来源证明和 SBOM：

CODE_TOKEN_8

Kubernetes：在准入阶段强制签名验证

对于 Kubernetes 部署，部署捆绑的 CODE_TOKEN_168，以便 https://docs.sigstore.dev/policy-controller/overview/ 拒绝任何未由本仓库 CODE_TOKEN_169 从 CODE_TOKEN_170 标签运行签名的 GitNexus 镜像——与上述 CODE_TOKEN_171 片段固定的身份相同。

CODE_TOKEN_9

完成后，尝试部署未签名镜像——或由 CODE_TOKEN_172 的 CODE_TOKEN_173 从非 CODE_TOKEN_174 标签签名的镜像——将在 Pod 创建前被准入 Webhook 拒绝。这会将可验证的签名转换为强制策略，这是大多数集群实际需要的供应链控制措施。

文件

• Dockerfile.web — 构建 CODE_TOKEN_175 和 CODE_TOKEN_176，然后提供生产环境前端服务。
• Dockerfile.cli — 构建 CLI/服务器（包含原生依赖）并运行 CODE_TOKEN_177。
• docker-compose.yaml — 同时启动两个已签名镜像。
• .env.example — 用于覆盖镜像名称、容器名称、端口和工作区挂载的配置。

Web UI 使用与 CLI 相同的索引管道，但完全在 WebAssembly 中运行（Tree-sitter WASM、LadybugDB WASM、浏览器内嵌入）。它适用于快速探索，但对于较大的仓库会受浏览器内存限制。

本地后端模式：运行 CODE_TOKEN_178 并在本地打开 Web UI——它会自动检测服务器并显示所有已索引的仓库，支持完整的 AI 聊天功能。无需重新上传或重新索引。智能体工具（Cypher 查询、搜索、代码导航）会自动通过后端 HTTP API 路由。

---

GitNexus 解决的问题

像 Cursor、Claude Code、Codex、Cline、Roo Code 和 Windsurf 这样的工具功能强大——但它们并不真正了解您的代码库结构。

实际情况：

1. AI 编辑 CODE_TOKEN_179
2. 不知道有 47 个函数依赖于其返回类型
3. 破坏性变更被发布

传统 Graph RAG 与 GitNexus

传统方法向 LLM 提供原始图边缘，并希望它进行足够的探索。GitNexus 在索引时预先计算结构——聚类、追踪、评分——因此工具可在一次调用中返回完整上下文：

CODE_TOKEN_10
--certificate-oidc-issuer https://token.actions.githubusercontent.com

正则表达式将证书身份固定到本仓库的 __CODE_TOKEN_163__ 工作流**从 __CODE_TOKEN_164__ 标签运行**——拒绝未签名镜像、由其他工作流签名的镜像以及从未受保护引用签名的镜像。两个仓库的验证规则相同，因为两组标签在同一工作流运行中以相同摘要签名。

**候选发布版本**——从 __CODE_TOKEN_165__ 签名（__CODE_TOKEN_166__ 调用 __CODE_TOKEN_167__ 作为可重用工作流时的调用者引用）：

__CODE_TOKEN_7__

您还可以检查构建来源证明和 SBOM：

__CODE_TOKEN_8__

#### Kubernetes：在准入阶段强制签名验证

对于 Kubernetes 部署，部署捆绑的 __CODE_TOKEN_168__，以便 [Sigstore policy-controller][policy-controller] 拒绝任何未由本仓库 __CODE_TOKEN_169__ 从 __CODE_TOKEN_170__ 标签运行签名的 GitNexus 镜像——与上述 __CODE_TOKEN_171__ 片段固定的身份相同。

__CODE_TOKEN_9__

完成后，尝试部署未签名镜像——或由 __CODE_TOKEN_172__ 的 __CODE_TOKEN_173__ 从非 __CODE_TOKEN_174__ 标签签名的镜像——将在 Pod 创建前被准入 Webhook 拒绝。这会将可验证的签名转换为强制策略，这是大多数集群实际需要的供应链控制措施。

[cosign-keyless]: https://docs.sigstore.dev/cosign/signing/overview/
[policy-controller]: https://docs.sigstore.dev/policy-controller/overview/

### 文件

- Dockerfile.web — 构建 __CODE_TOKEN_175__ 和 __CODE_TOKEN_176__，然后提供生产环境前端服务。
- Dockerfile.cli — 构建 CLI/服务器（包含原生依赖）并运行 __CODE_TOKEN_177__。
- docker-compose.yaml — 同时启动两个已签名镜像。
- .env.example — 用于覆盖镜像名称、容器名称、端口和工作区挂载的配置。

Web UI 使用与 CLI 相同的索引管道，但完全在 WebAssembly 中运行（Tree-sitter WASM、LadybugDB WASM、浏览器内嵌入）。它适用于快速探索，但对于较大的仓库会受浏览器内存限制。

**本地后端模式**：运行 __CODE_TOKEN_178__ 并在本地打开 Web UI——它会自动检测服务器并显示所有已索引的仓库，支持完整的 AI 聊天功能。无需重新上传或重新索引。智能体工具（Cypher 查询、搜索、代码导航）会自动通过后端 HTTP API 路由。

---

## GitNexus 解决的问题

像 **Cursor**、**Claude Code**、**Codex**、**Cline**、**Roo Code** 和 **Windsurf** 这样的工具功能强大——但它们并不真正了解您的代码库结构。

**实际情况**：

1. AI 编辑 __CODE_TOKEN_179__
2. 不知道有 47 个函数依赖于其返回类型
3. **破坏性变更被发布**

### 传统 Graph RAG 与 GitNexus

传统方法向 LLM 提供原始图边缘，并希望它进行足够的探索。GitNexus **在索引时预先计算结构**——聚类、追踪、评分——因此工具可在一次调用中返回完整上下文：

__CODE_TOKEN_10__