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

GitNexus

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

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

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

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

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

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

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

---

¹ 反重力钩子遵循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 是一个代码知识图谱的公共注册表，将 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` 事件，使注册表按需重新同步你的条目，而无需等待夜间作业。

这是可选功能，若没有 UNDERSTAND_QUICKLY_TOKEN（一个在注册表仓库上具有 Repository dispatches: write 权限的细粒度 GitHub PAT），则不会执行任何操作。不会发生其他事情；不会上传图谱文件。完整协议请参见 https://github.com/looptech-ai/understand-quickly/blob/main/docs/integrations/protocol.md%E3%80%82

Docker

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

[!IMPORTANT] 镜像重命名提示。早期版本的 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 身份通过 Cosign 无密钥签名 进行签名，并附带构建溯源信息和 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.]+)?

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

**候选发布版本**——从 `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 [***]

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

对于 Kubernetes 部署，可部署随附的 ClusterImagePolicy，使 Sigstore policy-controller 拒绝任何未由本仓库 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_116 标签运行的 CODE_TOKEN_117 工作流——拒绝未签名镜像、由其他工作流签名的镜像以及从未受保护引用签名的镜像。两个仓库的验证规则相同，因为两组标签在同一工作流运行中以相同摘要进行签名。

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

CODE_TOKEN_5

也可检查构建溯源信息和 SBOM：

CODE_TOKEN_6

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

对于 Kubernetes 部署，可部署随附的 CODE_TOKEN_121，使 Sigstore policy-controller 拒绝任何未由本仓库 CODE_TOKEN_122 从 CODE_TOKEN_123 标签运行签名的 GitNexus 镜像——与上述 CODE_TOKEN_124 片段固定的身份一致。

CODE_TOKEN_7

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

文件

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

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

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

---

GitNexus 解决的问题

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

实际情况：

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

传统 Graph RAG 与 GitNexus 的对比

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

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

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

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

__CODE_TOKEN_5__

也可检查构建溯源信息和 SBOM：

__CODE_TOKEN_6__

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

对于 Kubernetes 部署，可部署随附的 __CODE_TOKEN_121__，使 [Sigstore policy-controller][policy-controller] 拒绝任何未由本仓库 __CODE_TOKEN_122__ 从 __CODE_TOKEN_123__ 标签运行签名的 GitNexus 镜像——与上述 __CODE_TOKEN_124__ 片段固定的身份一致。

__CODE_TOKEN_7__

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

[cosign-keyless]: [***]
[policy-controller]: [***]

### 文件

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

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

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

---

## GitNexus 解决的问题

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

**实际情况**：

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

### 传统 Graph RAG 与 GitNexus 的对比

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

__CODE_TOKEN_8__