自建代码搜索引擎实战：OpenGrok vs Sourcegraph 选型与 Gitea 私有仓库集成方案

导语

在软件开发过程中，"找到代码"看似简单，实际上随着项目规模增长、团队人员流动、遗留系统积累，代码搜索逐渐成为影响开发效率的关键瓶颈。公有云代码搜索服务（如 GitHub Search）固然便利，但对于涉及安全合规、知识产权保护或纯内网环境的企业级场景，自建代码搜索引擎几乎是唯一选择。

当前自建代码搜索领域有两个主流方案：OpenGrok 和 Sourcegraph。两者定位差异显著——OpenGrok 是一个成熟的开源项目，侧重于源码级别的交叉引用（cross-reference）；Sourcegraph 则是商业化产品（提供开源社区版），主打语义级代码智能和大规模多仓库管理能力。选型决策不应仅看功能列表，还需结合团队规模、代码量级、硬件预算、语言生态等多维因素综合考量。

本文将从架构原理、部署成本、搜索性能、语言覆盖、AI 能力、Gitea 集成等角度，对二者进行深度技术对比，并提供可直接落地的 Gitea 私有仓库集成方案。

OpenGrok 详解

架构概述

OpenGrok 是 Oracle 发起并开源（CDDL 1.0 许可证）的源码搜索引擎，已有超过 20 年的发展历史。其核心架构基于 Java + Lucene + Universal Ctags 技术栈：

┌─────────────────────────────────────────────────┐
│                 Web UI (JSP)                     │
├─────────────────────────────────────────────────┤
│              Tomcat Servlet Container             │
├─────────────────────────────────────────────────┤
│         OpenGrok Web Application (WAR)           │
├──────────┬──────────────────────┬───────────────┤
│  SCMs    │   Lucene Index       │  Ctags Xref    │
│ (Git,    │   (全文倒排索引)       │  (符号交叉引用)  │
│  Hg, SVN)│                      │               │
├──────────┴──────────────────────┴───────────────┤
│            Filesystem (源码 + 索引数据)            │
└─────────────────────────────────────────────────┘

工作流程：OpenGrok Indexer 扫描指定目录下的源码文件，调用 Universal Ctags 生成符号定义（definitions、references），再由 Lucene 构建全文倒排索引和符号索引。索引完成后，用户通过 Web UI 或 REST API 进行搜索，引擎返回匹配结果并高亮显示符号交叉引用关系。

核心特性

全文搜索 + 符号导航：基于 Lucene 的全文检索配合 Ctags 生成的符号表，支持定义跳转和引用查找
增量索引：支持基于项目级别的增量索引更新（-I 参数），避免全量重建
SCM 历史集成：原生支持 Git、Mercurial、Subversion、Perforce，可直接查看 annotate/blame、diff 等历史信息
REST API：提供 /api/v1/search 接口，可编程调用搜索能力
权限控制：支持通过插件框架实现 Authentication/Authorization（如集成 LDAP）
Docker 部署：官方提供 Docker 镜像，降低部署门槛

局限性

搜索粒度为文本级别：本质上是基于 Lucene 的文本搜索引擎，不具备 AST 级别的语义理解能力。"Go to definition" 依赖 Ctags 的词法分析，对于同名重载、类型推导等复杂场景准确度有限
无原生 AI 集成：不具备代码智能问答、自然语言搜索等能力
大规模仓库支持有限：单个 OpenGrok 实例适合数十个项目或单个大型 monorepo，面对数百仓库的横向扩展能力较弱
Java 生态依赖重：需要 JDK + Tomcat，运维复杂度高于 Go 编写的同类工具

Sourcegraph 详解

架构概述

Sourcegraph 是用 Go 编写的代码搜索与智能平台，采用微服务架构，提供自托管（self-hosted）版本（社区版免费，商业版需许可证）。其核心架构可以概括为：

┌───────────────────────────────────────────────────┐
│                  Web Frontend (React)              │
├───────────────────────────────────────────────────┤
│               Sourcegraph Frontend (Go)           │
├─────────┬──────────┬──────────┬───────────────────┤
│ gitserver│ searcher │ codeintel│  other services   │
│(克隆仓库)│(分布式搜索)│(SCIP精确导航)│(API Server等)  │
├─────────┴──────────┴──────────┴───────────────────┤
│         PostgreSQL  │  Redis  │  Blob Storage     │
│         (元数据)     │ (缓存队列)│ (索引/代码intel)  │
└─────────────────────┴─────────┴───────────────────┘

关键子系统：

gitserver：负责通过 Git 协议克隆和更新远程仓库的本地镜像
searcher：基于 Zoekt（Google 开源的代码搜索库）的分布式搜索引擎，支持分片并行搜索
codeintel：运行 SCIP（Source Code Intelligence Protocol）索引器，生成精确的代码导航图谱
Precise Code Navigation：通过 SCIP 协议实现语言级的精确 "Go to definition"、"Find references"、"Find implementations" 功能

核心特性

毫秒级搜索：基于 Zoekt 的 trigram 索引 + 正则表达式搜索引擎，首次搜索即可达到毫秒级响应
语义级代码智能：通过 SCIP 协议提供精确的代码导航，覆盖数十种编程语言
大规模多仓库支持：官方声称支持 10 万级仓库，分布式架构可水平扩展
代码变更搜索（commit search）：支持基于 git log 的 diff 搜索，追踪代码变更历史
AI 能力（Deep Search + MCP）：内置 AI 代码搜索能力，支持通过 MCP（Model Context Protocol）与外部 AI 工具集成
浏览器扩展：支持在任何 Git 托管平台（GitHub、GitLab、Bitbucket 等）上直接跳转到 Sourcegraph 查看代码

局限性

资源需求高：完整部署需要大量 CPU 和内存资源，小型团队难以负担
部署复杂度：微服务架构涉及多个容器，Docker Compose 部署虽已简化，但运维（备份、升级、扩缩容）仍需一定经验
Gitea 集成非原生：没有官方的 Gitea Code Host 连接器，需要通过 Generic Git Host 方式手动配置
商业版许可证限制：社区版对用户数和部分企业功能有限制（如 Precision Code Navigation 在 Enterprise 计划中提供）

核心维度对比

部署成本对比

规模级别	OpenGrok 推荐配置	Sourcegraph 推荐配置
小型（< 1M 行代码 / < 100 仓库）	2-4 vCPU, 4-8 GB RAM, SSD	8 vCPU, 32 GB RAM, SSD (Docker Compose)
中型（1-10M 行代码 / 100-1000 仓库）	8 vCPU, 16 GB RAM, SSD	16-32 vCPU, 64-128 GB RAM, SSD
索引存储	约源码体积的 1-2 倍	约源码体积的 2-5 倍（含 SCIP 索引）
最低运行时依赖	JDK 17+, Tomcat 10+, Universal Ctags	Docker 18+, Docker Compose
操作系统要求	任意（跨平台 Java）	仅 Linux（不支持 Windows/ARM 生产部署）

关键差异解读：

OpenGrok 的硬件门槛极低，一台 4 核 8GB 的 VPS 即可运行小型部署；Sourcegraph 的最低要求直接拉到 8 核 32GB，这意味着云上部署的月度成本至少是 OpenGrok 的 4-8 倍
索引存储方面，OpenGrok 的 Lucene 索引相对紧凑（约源码 1-2 倍），Sourcegraph 除 Zoekt 索引外还需存储 SCIP codeintel 数据、仓库克隆等，总占用更大

搜索性能对比

指标	OpenGrok	Sourcegraph
首次单关键词搜索	5-10 秒（冷启动需加载 Lucene Segment）	毫秒级（Zoekt trigram 索引）
后续搜索	亚秒级（Lucene 缓存命中后）	毫秒级（始终稳定）
正则表达式搜索	支持但性能随复杂度下降显著	原生高性能正则引擎
跨仓库搜索	单次查询所有已索引项目	分布式并行搜索，10 万仓库级别
代码导航精度	基于文本匹配，同名符号容易混淆	SCIP 协议提供 AST 级精确导航

关键差异解读：

OpenGrok 的首次搜索延迟是 Lucene 引擎的固有问题——首次查询需要打开索引文件（Open index segment），这在 JVM 上表现为明显的冷启动延迟。后续查询因 Lucene 的 OS 缓存和 JVM 缓存命中，性能可以到亚秒级
Sourcegraph 基于 Zoekt，其核心是一个专为代码搜索优化的 trigram 索引引擎。trigram 索引在搜索前将查询表达式拆解为三字符组合（trigrams），先在索引中快速定位候选文档，再在候选集上执行完整正则匹配，从而实现毫秒级响应
代码导航精度是根本性差异：OpenGrok 的 Ctags 只做词法分析（识别函数名、变量名），不区分类型上下文；Sourcegraph 的 SCIP 由各语言的 Language Server 生成索引，包含完整的类型解析信息

功能矩阵对比

功能维度	OpenGrok	Sourcegraph
许可证	开源（CDDL 1.0）	社区版开源（Apache 2.0）/ 商业版
核心语言	Java	Go（微服务）
搜索引擎	Apache Lucene	Zoekt（trigram + regex）
代码导航	Universal Ctags（文本级）	SCIP（语义级）
支持语言数	通过 Ctags 扩展（数十种）	原生数十种 + SCIP 扩展
SCM 集成	Git, Hg, SVN, Perforce	通过 Git 协议连接任意代码托管
最大仓库数	数十项目 / 单 monorepo	10 万仓库级别
增量索引	项目级别增量	仓库级别增量（gitserver 自动 pull）
REST API	`/api/v1/search`	完整 GraphQL API
浏览器扩展	无	Chrome/Firefox 扩展
代码变更搜索	有限（SCM log 查看）	完整 commit/diff 搜索
AI 代码搜索	无	Deep Search + MCP
权限模型	插件框架	内置 RBAC
Gitea 原生支持	无（手动集成）	无官方连接器（Generic Git Host）
部署方式	WAR/Tomcat/Docker	Docker Compose / Kubernetes

Gitea 集成方案

方案一：OpenGrok + Gitea（Webhook/Cron 触发索引）

这是最成熟且文档最丰富的集成方式。核心思路是：当 Gitea 仓库有代码变更时，自动触发 OpenGrok 重新索引对应项目。

架构示意

┌──────────┐  push hook   ┌──────────────────┐
│  Gitea   │─────────────>│  Webhook Receiver │
│  Server  │              │  (nginx/flask/    │
└────┬─────┘              │   自定义脚本)      │
     │                    └────────┬─────────┘
     │ git pull/clone              │ 触发 indexer
     │ (OpenGrok 直接读源码)        │
     v                             v
┌──────────────────────────────────────────┐
│           OpenGrok Indexer                │
│  opengrok-indexer -s /src -d /data -I $REPO│
└──────────────────┬───────────────────────┘
                   │ 写入索引
                   v
┌──────────────────────────────────────────┐
│       OpenGrok Data (Lucene + Xref)      │
└──────────────────────────────────────────┘

实现步骤

步骤 1：OpenGrok 基础部署

# 使用 Docker 部署 OpenGrok
docker run -d \
  --name opengrok \
  -p 8080:8080 \
  -v /data/opengrok/src:/var/opengrok/src \
  -v /data/opengrok/data:/var/opengrok/data \
  -v /data/opengrok/etc:/var/opengrok/etc \
  opengrok/docker:latest

步骤 2：配置 Gitea Webhook

在 Gitea 的每个仓库设置中添加 Webhook：

URL：http://<opengrok-host>:<port>/webhook
Content Type：application/json
Secret：自定义密钥（用于验证请求来源）
Trigger Events：Push events

步骤 3：编写 Webhook 接收脚本

#!/bin/bash
# /usr/local/bin/opengrok-webhook.sh
# 接收 Gitea Webhook 并触发增量索引

RECEIVE_SECRET="your-webhook-secret"
SRC_ROOT="/data/opengrok/src"
DATA_ROOT="/data/opengrok/data"

# 读取 stdin 的 JSON payload
payload=$(cat)

# 验证 secret
secret=$(echo "$payload" | jq -r '.secret // empty')
if [ "$secret" != "$RECEIVE_SECRET" ]; then
    echo "Unauthorized" >&2
    exit 1
fi

# 提取仓库名称
repo_name=$(echo "$payload" | jq -r '.repository.full_name // empty')
if [ -z "$repo_name" ]; then
    echo "Invalid payload" >&2
    exit 1
fi

# 将 Gitea 仓库路径映射到 OpenGrok 源码目录
project_path="$SRC_ROOT/$repo_name"

# 更新仓库（git pull）
if [ -d "$project_path/.git" ]; then
    cd "$project_path"
    git pull --ff-only origin HEAD
else
    # 首次克隆
    git clone http://<gitea-user>:<token>@gitea:3000/$repo_name.git "$project_path"
fi

# 对该仓库执行增量索引
docker exec opengrok \
  /usr/local/opengrok/bin/opengrok-indexer \
  -s /var/opengrok/src \
  -d /var/opengrok/data \
  -I "$repo_name" \
  -c /usr/bin/ctags

echo "Index updated for $repo_name"

步骤 4：配置 Nginx 接收 Webhook

server {
    listen 8081;
    server_name _;

    location /webhook {
        proxy_pass http://unix:/run/opengrok-webhook.sock;
    }
}

步骤 5（备选）：使用 Cron 定时全量同步

对于不要求实时性的场景，Cron 是最简单的方案：

# 每 30 分钟执行一次增量索引
*/30 * * * * docker exec opengrok \
  /usr/local/opengrok/bin/opengrok-indexer \
  -s /var/opengrok/src \
  -d /var/opengrok/data \
  -c /usr/bin/ctags \
  >> /var/log/opengrok-sync.log 2>&1

# 每天凌晨执行全量索引（可选）
0 2 * * * docker exec opengrok \
  /usr/local/opengrok/bin/opengrok-indexer \
  -s /var/opengrok/src \
  -d /var/opengrok/data \
  -W /var/opengrok/etc/configuration.xml \
  -c /usr/bin/ctags \
  -r 2 \
  >> /var/log/opengrok-full.log 2>&1

注意事项

OpenGrok 需要直接读取源码文件（文件系统访问），而非通过 Git 协议克隆。因此要么将 Gitea 仓库的裸仓库目录直接挂载，要么在索引服务器上维护一份镜像克隆
增量索引（-I 参数）的性能取决于变更的文件数量。对于频繁提交的大型仓库，增量索引可能需要几十秒到几分钟
如需权限隔离（不同用户只能搜索自己有权限的仓库），需借助 OpenGrok 的 Authorization 插件，并与 Gitea 的权限模型联动

方案二：Sourcegraph + Gitea（Generic Git Host）

Sourcegraph 没有官方的 Gitea Code Host 连接器（官方支持 GitHub、GitLab、Bitbucket、Phabricator 等），但可以通过 Generic Git Host 方式连接任何 Git 服务器。

实现步骤

步骤 1：部署 Sourcegraph

# 克隆部署脚本
git clone https://github.com/sourcegraph/deploy-sourcegraph.git
cd deploy-sourcegraph/docker-compose

# 修改配置
# 在 docker-compose.yml 中根据资源调整各服务资源限制

# 启动
docker-compose up -d

步骤 2：配置 Generic Git Host 连接

在 Sourcegraph 管理后台：

进入 Site admin > Manage code hosts > Add repositories
选择 Generic Git Host
配置连接参数：

{
  "url": "http://gitea:3000",
  "repos": [
    "http://gitea:3000/myorg/repo1",
    "http://gitea:3000/myorg/repo2"
  ],
  "ssh": {
    "knownHosts": "gitea ssh-rsa AAAA...",
    "privateKey": "-----BEGIN OPENSSH PRIVATE KEY-----..."
  }
}

对于使用 SSH 的场景，需在 Sourcegraph 容器中配置 SSH Key：

# 将 SSH 私钥注入 Sourcegraph 的 gitserver 容器
docker cp ~/.ssh/id_rsa sourcegraph-gitserver-1:/root/.ssh/id_rsa
docker exec sourcegraph-gitserver-1 chmod 600 /root/.ssh/id_rsa

对于使用 HTTP Token 的场景：

{
  "url": "http://gitea:3000",
  "repos": "http://<token>@gitea:3000/myorg/*",
  "git.cloneURLHostsWithSSH": []
}

步骤 3：配置自动仓库发现（可选）

Sourcegraph 支持通过 Generic Git Host 的 repos 字段使用通配符（*）自动发现指定组织下的所有仓库。但需要注意：

每次 UI 保存配置后，Sourcegraph 会尝试解析通配符并发现新仓库
如需完全自动化，可使用 Sourcegraph 的 GraphQL API：

curl -X POST http://sourcegraph:7080/.api/graphql \
  -H "Authorization: token <access-token>" \
  -H "Content-Type: application/json" \
  -d '{
    "query": "mutation { addExternalService(connection: { displayName: \"Gitea\", kind: GENERIC, generic: { url: \"http://gitea:3000\", repos: \"http://token@gitea:3000/myorg/*\", credential: { ssh: null, password: null } } }) { id } }"
  }'

注意事项

Generic Git Host 方式不支持以下功能（因为是 Generic 连接器）：代码审查集成、PR/MR 状态同步、浏览器扩展的自动跳转。这些功能需要 Tier 1 Code Host（如 GitHub/GitLab）才支持
仓库更新频率由 Sourcegraph 的 gitserver 定期 git fetch 决定，默认每分钟检查一次。可通过 gitserver 配置调整更新间隔
如果 Gitea 实例在反向代理后面，需确保 clone URL 可被 Sourcegraph 的 gitserver 访问

集成方案选型建议

场景	推荐方案	理由
代码量 < 1M 行，团队 < 10 人	OpenGrok + Gitea Webhook	资源需求极低，部署简单，够用
代码量 1-10M 行，需要代码导航精度	Sourcegraph + Gitea Generic Git Host	SCIP 提供精确导航，值得资源投入
需要实时索引更新	OpenGrok + Gitea Webhook	Webhook 直接触发，延迟可控
需要 AI 代码搜索能力	Sourcegraph + Gitea Generic Git Host	唯一内置 AI 能力的方案
严格内网环境，无 Docker	OpenGrok + Gitea Cron	WAR 包部署，依赖最少

替代方案一览

除 OpenGrok 和 Sourcegraph 外，还有一些值得关注的自建代码搜索方案：

Zoekt

来源：Google 开源（Sourcegraph 维护的 Go 库）
特点：trigram 索引引擎，专为代码搜索优化，毫秒级响应；支持分布式搜索（Web 索引服务架构）
适用场景：需要高性能正则搜索但不需要 Sourcegraph 完整平台功能时，可单独部署 Zoekt
与 Gitea 集成：Zoekt 支持通过 zoekt-mirror-github 或自定义脚本定期 git clone + zoekt-index，对 Gitea 同理
局限：无 Web UI（需自建或使用 sourcegraph 的 searcher），无代码导航，无 AI 能力

Hound

来源：Stripe 开源的 Go 代码搜索引擎
特点：极轻量，单二进制文件部署，内置 Web UI，基于 Regex 搜索
适用场景：代码量在 GB 级别以下，追求极致部署简洁性
与 Gitea 集成：配置文件中直接指定 Gitea 仓库的 Git clone URL 即可，Hound 自动拉取和索引
局限：不支持代码导航、无权限控制、项目活跃度低（近年更新较少）

Elasticsearch + Kythe/SCIP

思路：使用通用搜索引擎（Elasticsearch）作为底层，搭配代码智能索引工具（Google Kythe 或 Sourcegraph SCIP）提供代码导航
特点：最大灵活性，可深度定制搜索和导航体验；Elasticsearch 生态成熟，运维经验丰富
适用场景：已有 Elasticsearch 集群、对代码搜索有高度定制化需求的企业
局限：集成复杂度极高——需要自建 Kythe/SCIP 索引管道、自定义搜索 UI、维护索引同步机制，工程量远超直接使用 OpenGrok 或 Sourcegraph

方案对比速览

方案	部署复杂度	搜索速度	代码导航	多仓库	AI 能力	维护活跃度
OpenGrok	中	秒级（首次）/ 亚秒级	Ctags 文本级	数十项目	无	高
Sourcegraph	高	毫秒级	SCIP 语义级	10 万仓库	Deep Search + MCP	高（商业）
Zoekt	中	毫秒级	无	中等	无	中
Hound	低	毫秒级	无	有限	无	低
ES + Kythe/SCIP	极高	依赖调优	AST 级	大规模	需自建	依赖组件

个人技术观点

在经过多次实际部署和选型评估后，我的核心建议如下：

小团队优先选择 OpenGrok。如果你的团队代码量在百万行以内、仓库数量在数十个级别，OpenGrok 几乎是性价比最高的选择。它的硬件门槛极低（一台 4 核 8GB 的机器就能跑），部署和维护简单，Ctags 生成的符号交叉引用对于日常的代码查找已经足够。与 Gitea 的 Webhook 集成方案成熟可靠，整体运维负担可控。

中大型团队认真考虑 Sourcegraph。如果你的代码分布在数百个仓库中，或者团队对代码导航精度有较高要求（尤其是多语言混合项目），Sourcegraph 的 SCIP 协议和毫秒级搜索带来的效率提升是实打实的。但要做好资源规划——最低 8 核 32GB 的硬件要求意味着年化云成本可能达到数万元。

Gitea 集成是选型的关键变量。客观地说，两个方案对 Gitea 的支持都不算原生。OpenGrok 的优势在于它的 Webhook 方案是"够用"级别的，直接读文件系统的设计天然兼容私有仓库；Sourcegraph 的 Generic Git Host 方式能用，但缺失了代码审查集成等高级功能。如果你的工作流深度依赖 Gitea 的 PR/Review 流程与代码搜索的联动，目前没有一个完美方案，可能需要额外的定制开发。

关注 Zoekt 作为独立方案。如果你只需要"代码里搜文字"的能力，不需要代码导航和 AI，直接部署 Zoekt 是一个高性能且轻量的选择。它是 Sourcegraph 搜索引擎的底层，搜索性能与 Sourcegraph 一致，但资源消耗远低于完整的 Sourcegraph 平台。

不要低估 AI 代码搜索的趋势。Sourcegraph 的 Deep Search 和 MCP 集成代表了代码搜索的未来方向——从"找到文本"到"理解意图"。虽然目前 AI 代码搜索在私有化部署中仍处于早期阶段，但对于规划 3-5 年基础设施的团队，建议将 AI 能力纳入选型考量。

参考来源

OpenGrok 官方仓库：https://github.com/OpenGrok/OpenGrok
OpenGrok 集群部署方案与硬件推荐：CSDN - OpenGrok 集群部署方案
OpenGrok 安装配置与性能说明：CSDN - OpenGrok 安装配置说明
OpenGrok 实际搜索延迟说明（Fedora Wiki）：https://fedoraproject.org/wiki/LubomirKundrak/OpenGrok
Sourcegraph 官方文档 - Docker Compose 部署：https://sourcegraph.com/docs/admin/deploy/docker-compose
Sourcegraph 官方文档 - Precise Code Navigation：https://sourcegraph.com/docs/code-navigation/precise-code-navigation
Sourcegraph SCIP 协议公告：https://sourcegraph.com/blog/announcing-scip
Sourcegraph Code Host 连接文档：https://sourcegraph.com/docs/admin/code-hosts
Sourcegraph Generic Git Host 配置：https://sourcegraph.com/docs/admin/code-hosts/other
Sourcegraph Gitea 集成讨论：https://bleepingcoder.com/sourcegraph/377622948/gitea-integration-support
Zoekt 项目：https://github.com/sourcegraph/zoekt
Hound 项目：https://github.com/hound-search/hound
Universal Ctags 文档：https://docs.ctags.io/en/latest/

技术免责声明

本文所涉及的技术方案、性能数据、配置参数均基于作者的实际部署经验以及公开文档资料整理而成。具体性能表现会受到硬件配置、网络环境、代码库特征、索引策略等多种因素的影响，实际结果可能与本文描述存在差异。文中的硬件推荐配置仅供参考，建议在正式部署前结合实际场景进行容量评估和压力测试。文中引用的第三方产品（OpenGrok、Sourcegraph、Gitea、Zoekt、Hound 等）的许可证条款和功能范围可能随版本更新而变化，请以各项目官方最新文档为准。本文不构成任何商业采购建议，读者应根据自身需求和预算独立做出技术选型决策。

posted on 2026-07-12 20:31 0xfisher 阅读(12) 评论(0) 收藏举报

刷新页面返回顶部

导航

公告

自建代码搜索引擎实战：OpenGrok vs Sourcegraph 选型与 Gitea 私有仓库集成方案

目录

导语

OpenGrok 详解

架构概述

核心特性

局限性

Sourcegraph 详解

架构概述

核心特性

局限性

核心维度对比

部署成本对比

搜索性能对比

功能矩阵对比

Gitea 集成方案

方案一：OpenGrok + Gitea（Webhook/Cron 触发索引）

架构示意

实现步骤

注意事项

方案二：Sourcegraph + Gitea（Generic Git Host）

实现步骤

注意事项

集成方案选型建议

替代方案一览

Zoekt

Hound

Elasticsearch + Kythe/SCIP

方案对比速览

个人技术观点

参考来源

技术免责声明