ghcr.io/abhigyanpatwari/gitnexus:1.6.8-rc.50

GitNexus

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

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

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

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

将任何代码库索引到知识图谱中——包括所有依赖项、调用链、集群和执行流——然后通过智能工具公开，确保AI智能体不会遗漏代码。

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

简而言之：Web UI 是与任何仓库快速交互的方式。CLI + MCP 则是确保AI智能体真正可靠的方法——它为Cursor、Claude Code、Antigravity、Codex等工具提供代码库的深度架构视图，防止它们遗漏依赖项、破坏调用链和进行盲目编辑。即使是较小的模型也能获得完整的架构清晰度，使其能与大型模型竞争。

¹ Antigravity 钩子遵循*** CLI钩子参考（Antigravity 2.0是*** CLI的官方后续版本）。增强在AfterTool中运行，因为在协议中BeforeTool没有上下文注入通道——代理通过hookSpecificOutput.additionalContext看到附加到工具结果的图上下文。成功执行git commit/merge/rebase/cherry-pick/pull后，过时索引提示会进入同一通道。如果Antigravity特定的钩子文档与 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 则不执行任何操作——UNDERSTAND_QUICKLY_TOKEN 是一个细粒度 GitHub PAT，在 registry 仓库上具有 Repository dispatches: write 权限。不会发生其他操作；不会上传图谱文件。完整协议参见 https://github.com/looptech-ai/understand-quickly/blob/main/docs/integrations/protocol.md%E3%80%82

你的 AI 智能体获得的功能

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

Web UI（基于浏览器）

客户端图形浏览器和 AI 聊天工具 — 您的代码始终不会离开您的设备。

立即试用： https://gitnexus.vercel.app — 在本地运行 npx gitnexus@latest serve，页面会自动连接到您的本地后端。

或者在本地运行前端：

git clone https://github.com/abhigyanpatwari/gitnexus.git
cd gitnexus/gitnexus-shared && npm install && npm run build
cd ../gitnexus-web && npm install
npm run dev
# 然后在另一个终端中，启动前端连接的后端：
npx gitnexus@latest serve

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 分支的浮动构建。两个 registry 从同一构建步骤获得相同的摘要，因此可从任一来源拉取，签名验证结果完全一致。
• 候选发布镜像（如 :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 证明。这是抵御供应链的保护机制**：即使**者在其他位置重新发布同名镜像（或通过某种方式推送到仿冒 registry），也无法伪造与 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*` 标签运行**——拒绝未签名镜像、由其他工作流签名的镜像以及从非保护引用签名的镜像。两个 registry 的验证规则相同，因为两组标签在同一工作流运行中以相同摘要签名。

**候选发布版本**——从 `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* 标签签名的镜像时，准入 Webhook 将在 Pod 创建前拒绝请求。这将可验证签名转化为强制策略，是大多数集群实际需要的供应链控制措施。

文件

• 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_129 工作流从 CODE_TOKEN_130 标签运行——拒绝未签名镜像、由其他工作流签名的镜像以及从非保护引用签名的镜像。两个 registry 的验证规则相同，因为两组标签在同一工作流运行中以相同摘要签名。

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

CODE_TOKEN_6

也可检查构建溯源和 SBOM：

CODE_TOKEN_7

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

对于 Kubernetes 部署，部署捆绑的 CODE_TOKEN_134，使 https://docs.sigstore.dev/policy-controller/overview/ 拒绝任何未由本仓库 CODE_TOKEN_135 从 CODE_TOKEN_136 标签运行签名的 GitNexus 镜像——与上述 CODE_TOKEN_137 片段固定的身份一致。

CODE_TOKEN_8

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

文件

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

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

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

---

GitNexus 解决的问题

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

问题场景：

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

传统 Graph RAG 与 GitNexus

传统方法向 LLM 提供原始图边缘并依赖其充分探索。GitNexus 在索引时预计算结构——聚类、追踪、评分——使工具能在一次调用中返回完整上下文：

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

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

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

__CODE_TOKEN_6__

也可检查构建溯源和 SBOM：

__CODE_TOKEN_7__

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

对于 Kubernetes 部署，部署捆绑的 __CODE_TOKEN_134__，使 [Sigstore policy-controller][policy-controller] 拒绝任何未由本仓库 __CODE_TOKEN_135__ 从 __CODE_TOKEN_136__ 标签运行签名的 GitNexus 镜像——与上述 __CODE_TOKEN_137__ 片段固定的身份一致。

__CODE_TOKEN_8__

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

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

### 文件

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

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

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

---

## GitNexus 解决的问题

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

**问题场景**：

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

### 传统 Graph RAG 与 GitNexus

传统方法向 LLM 提供原始图边缘并依赖其充分探索。GitNexus **在索引时预计算结构**——聚类、追踪、评分——使工具能在一次调用中返回完整上下文：

__CODE_TOKEN_9__