gtr (Git Worktree Runner)：让四个 AI 编程助手同时住进同一个仓库

图：gtr 官方演示，四个 AI 编程助手分别在四个 worktree 中并行工作，互不干扰。

想象这样一个场景：你让 AI 帮我修一个登录接口的 bug，同时又让它去实现一个全新的大版本功能，还想顺手把线上 PR #123 的代码拉到本地审一遍。传统 Git 做不到——一个工作目录同一时刻只能 checkout 一个分支，改完不提交就得 stash、checkout、切回来，来回折腾。AI 编程时代这个矛盾被放大了：一个项目同时派出三四个智能体是常态，它们全都想独占一个干净目录。

gtr 就是来解决这件事的。它是 CodeRabbit 团队开源的一款 Bash 命令行工具，把 Git 原生 worktree 能力包成了"一次命令、开箱即用"的工作区管理器：自动创建隔离目录、自动复制 .env 和配置文件、自动跑依赖安装钩子、自动拉起 Cursor 或 Claude Code。

从原生 worktree 到 gtr：补上 DX 的那一截

Git 2.5 就自带 git worktree 了，功能很强，但原始命令啰嗦且易错：git worktree add ../repo-feature feature，路径要自己规划、分支名带斜杠会生成难看的目录名、配置文件不会带过去、依赖不会装、编辑器不会自动打开。gtr 提供的价值不在于"新增能力"，而在于把每一步的仪式感抹平：

生活化的比喻：原生 worktree 像一给你一堆毛坯钥匙和图纸，自己还得找施工队；gtr 则是拎包入住的公寓——水电网络全通，家具按你的偏好摆好，钥匙在门口。

核心功能盘点

1. 仓库级隔离。 每个仓库拥有自己独立的 worktree 命名空间，.gtrconfig 按仓库配置默认分支、默认远程、默认编辑器和默认 AI 工具。

2. AI 工具适配器注册表。 内置适配器覆盖 aider、auggie、codex、continue、copilot、gemini、opencode、antigravity 等 AI CLI，以及 antigravity、atom、cursor、emacs、idea、nvim、pycharm、sublime、vim、vscode、webstorm、zed 等编辑器。特殊启动逻辑的走 adapters/ai/claude.sh、adapters/ai/cursor.sh、adapters/editor/nano.sh 自定义文件，其余走安全的 PATH 兜底查找——任何 PATH 里的命令行工具都能用，不必官方适配。

3. 为 AI 智能体设计的机器可读输出。 这是最见功力的设计。git gtr new agent/my-task --porcelain 会在 stdout 严格输出三行制表符分隔记录：path、branch、hook_status，所有进度消息、警告、钩子输出一律走 stderr。hook_status 有五种取值：disabled（显式关闭钩子）、none（未配置）、ran（全部执行成功）、skipped-untrusted（只有未信任的钩子被跳过）、partial（部分执行）。智能体拿到这个输出就能可靠解析路径并进入目录干活，非零退出码即代表创建、复制或钩子失败。

4. 安全信任模型。 仓库里提交的 .gtrconfig 钩子等价于"授权执行代码"，因此默认不信任，必须由人显式 git gtr trust 批准。官方在 docs/agent-usage.md 里明确要求：Agent 不应自行执行 git gtr trust，也不应擅自使用 git gtr rm --force、--delete-branch、git gtr clean。

5. 钩子体系。 postCreate、preRemove、postRemove、postCd 四类钩子，覆盖"建完装依赖"到"删完通知"的全流程。

6. 可复制的测试与文档体系。 仓库有 48 个 bats 测试文件，覆盖 init、copy、hooks、sparse-checkout、裸仓库、provider 识别、信任存储等模块，测试代码量超过产品代码量；文档含 README、configuration.md、advanced-usage.md、agent-usage.md、troubleshooting.md 五份，以及 AGENTS.md 与 CLAUDE.md 两份给 AI 读的项目指南。

上手门槛：CLI 党与图形界面党的分野

gtr 是纯 CLI 工具，没有 Web UI，也不提供 Dockerfile / docker-compose——它本就该装在你本机的开发环境里，而不是容器里。

安装有三条路：macOS 用 Homebrew brew tap coderabbitai/tap && brew install git-gtr；macOS/Linux/Windows Git Bash 可克隆源码跑 ./install.sh；也可以手动把 bin/git-gtr 软链到 /usr/local/bin 或 ~/.local/bin。硬性依赖只有两个：Git 2.17+（用到了 git worktree move/remove）和 Bash 3.2+（macOS 自带的就是 3.2）。额外可选依赖是 gh/glab（PR 检出与清理）、fzf（交互式 gtr cd 选择器）、以及 shell 集成（--cd 直接切目录）。

Windows 用户注意：安装器只会提示把 checkout 的 bin 目录加进 PATH，且必须保留完整 checkout，不能只拷贝 bin/git-gtr 一个文件，因为启动需要同目录的 lib 库。

争议与局限

它到底算不算 AI 项目？ gtr 本体没有任何模型调用，它是纯粹的 Git 工作流工具。AI 相关性体现在"为 AI 编程工作流而生"——AI 适配器、智能体输出契约、AGENTS.md 策略模板都是为多智能体并行服务。这是一把刀，不是引擎。

Bash 的天花板。 纯 Bash 实现带来极低的安装成本和零运行时依赖，但也意味着跨平台行为差异（macOS 的 Bash 3.2 vs Linux 4.0+）需要靠大量平台分支处理，测试矩阵成本高。

配置复杂度不低。 gtr.copy.include/exclude 多值通配、gtr.sparse.inherit、gtr.hook.*、作用域（仓库级 vs 全局），加上 trust 机制，初次配置的学习曲线比"直接敲 git worktree add"陡。

功能重叠。 社区已有 tmuxinator、git-worktree-manager 等方案，gtr 的差异化主要在 AI 适配器和钩子自动化，而非 worktree 本身。

破坏性操作有风险。 --force 允许同一分支在多个 worktree 同时 checkout（这是多智能体并行写同一分支的必要能力），但并发编辑必然产生冲突，官方文档也反复提醒。

行业意义

gtr 折射出的趋势是明确的：AI 编程正在把"开发者工作区"从单目录变成多目录并行。单智能体时代 git stash 就够用，多智能体时代每个 Agent 都要一个隔离目录，这是从工具层面硬性长出来的需求。CodeRabbit 作为 AI Code Review 团队，把 AI 工作流的工程直觉做进了一个小工具里，这本身就是一种信号——AI 辅助开发的周边基础设施正在被系统性补齐。

从数据看：项目 2025 年 8 月开源，截至目前约 1800 星、114 fork，29 位贡献者，Apache-2.0 许可，最新版本 v3.0.0（2026-10-28），仍在高频迭代。团队规模不大但产出密度极高——CHANGELOG 细到记录 set -e 改为 set -eE 让 ERR trap 生效这种级别的修复。

对于想用 AI 并行开发、又不想被 git stash 折腾的团队，gtr 值得放进工具箱。但请记住它的定位：一款打磨精良的 Git 工作区管理器，AI 是它最优先服务的场景，而不是它的全部。