开发者 haoguan2013 在 V2EX 发布开源工具 GitTracer，用于解决多仓库项目发版前的核对难题。其项目拆分为七八个仓库，每次发版前需逐个进入目录执行 git status，确认没有漏提交、漏推送或停留在 rebase 中间状态，每月重复两三次、每次耗时十几分钟，且总会有遗漏。作者最初尝试用 for 循环脚本批量检查，但输出为流式日志，难以从数百行文件名中得出结论，且脚本仅能在本机运行。市面上的 gfold、RepoZ 等多仓库看板工具虽界面美观，但回答的是“当前状态如何”，而非发版前需要的“这次能否发布”。GitTracer 的核心功能是扫描指定目录找出所有 Git 仓库，在一屏内展示状态；点击“巡检”后按固定规则逐仓判定通过或未通过，报告可复制为 Markdown 直接粘贴进发版单。规则可写入 .gittracer.toml 配置文件随仓库分发，命令行版本 gittracer-audit 读取同一份配置，通过退出码 0/1/2 直接接入 CI 流水线。工具明确列出局限：仅支持 Windows、巡检不执行 git fetch、不做 hunk 暂存与交互式 rebase、只判不改。整个工具 1.8MB 免安装，源码托管于 GitHub。作者同时公开征集反馈，希望了解其他团队发版前的核对清单，以补充现有 11 条规则中可能缺失的项目。
事件分析
这款工具的技术看点在于“规则与界面分离”的架构决策：判定逻辑独立于 GUI，使人工点击与 CI 自动执行产出一致结论，这是其区别于 gfold、RepoZ 等状态可视化工具的关键。退出码 0/1/2 的设计遵循 Unix 传统，大幅降低接入 Jenkins、GitHub Actions 等流水线的成本。从产业视角看，微服务与多仓库架构普及后，跨仓库发版核对成为中小团队的普遍痛点，该工具提供了一种轻量级解法——不引入重型发布平台，而是将检查清单固化为可执行规则。可能的后续走向包括跨平台支持（当前依赖 WinForms 是主要限制）、与发版单系统的深度集成，以及规则集合随社区反馈的持续沉淀。值得注意的是，巡检不执行 git fetch 意味着“落后远程”的判定基于本地缓存，在弱网或多人协作场景下可能产生偏差。作者公开征集各团队发版核对清单的做法，也可能使其规则库逐渐演变为社区发版实践的事实参考。
核心观点：发版核对的关键不是“看见状态”而是“得出结论”，把人工经验固化为机器可执行规则，才是发版自动化的真正起点。
原文链接：V2EX 分享发现
评论前必须登录！
立即登录 注册