【Gemini CLI：重新定义命令行AI开发】06 加餐篇 - 多分支开发工作流：与Git Worktree的高效协同

请点击上方蓝字TonyBai订阅公众号！

大家好，我是Tony Bai。

想象一个你再熟悉不过的场景：

你正在一个复杂的新功能分支 feature/new-api 上奋战。你的终端里，与 Gemini CLI 的对话已经进行了数十轮，AI 对你正在开发的 internal/api 模块了如指掌。你们刚刚通过 @ 命令分析完好几个 Go 文件，正处在灵感迸发的“心流”状态。

突然，“叮”——线上告警，一个紧急的 bug 需要你立刻放下手头的一切去修复。

你的第一反应是什么？大概率是这一套标准连招：

1. 手忙脚乱地 git stash 保存当前的工作进度。

2. git checkout main 然后 git pull，再 git checkout -b hotfix/bug-123。

3. 打开新的文件，开始定位问题。

当你准备再次向 Gemini CLI 求助时，你点开那个终端窗口，心头一凉——完了。

你之前与 AI 关于 feature/new-api 的所有对话历史、所有 @ 注入的上下文、所有 AI 形成的对你模块的“短期记忆”，都随着你切换分支而变得毫无意义。AI 从一个与你并肩作战的“资深同事”，瞬间退化回了“第一天入职的新人”。等你修复完 bug 切回功能分支，你和 AI 都得重新“预热”，宝贵的专注力和生产力就这样付诸东流。

这就是 AI 原生开发时代的“上下文灾难”。在今天这篇文章中，我们将学习如何利用 Git 的一个“隐藏神器”—— git worktree，来彻底终结这场灾难，让你和你的 AI 伙伴都能拥有独立、专注的“平行宇宙”。

“旧世界”的困境：git checkout 如何“格式化”你的 AI 大脑