用 AI 编程助手玩转 Git 高阶操作

Git 是 AI 编程助手（Coding Agents）的关键工具。把代码放进版本控制，就能记录变化、排查错误、随时回滚。所有编程助手都精通 Git 的基础和高级功能。

这意味着我们可以更大胆地使用 Git。不用死记硬背操作命令，只要知道 Git 能做什么，就能充分利用它的全部能力。

Git 基础

每个 Git 项目都存在于一个仓库（Repository）里——这是磁盘上的一个文件夹，能追踪其中文件的改动。这些改动记录在提交（Commit）中：带时间戳的变更包，包含一个或多个文件的修改，附有描述改动的提交信息（Commit Message）和记录操作者的作者（Author）信息。

Git 支持分支（Branches），让你可以独立构建和试验新功能。分支完成后，可以通过多种方式合并（Merge）回主分支。

Git 仓库可以克隆（Cloned）到新机器上，克隆体包含当前文件及其完整历史记录。这样开发者——或者编程助手——就能在不产生额外网络流量的情况下浏览历史，探索代码演变过程几乎是零成本的。

Git 仓库可以只存在于本地，但 Git 的设计支持通过发布到远程仓库（Remote）进行协作和备份，远程仓库可以是公开或私有的。GitHub 是最流行的远程托管平台，但 Git 是开源软件，任何支持 Git 协议的机器或服务都能托管远程仓库。

核心概念与提示词

编程助手都深刻理解 Git 术语。以下提示词对它们都适用：

• 把助手当前工作的文件夹变成 Git 仓库——助手可能会运行 git init 命令。如果你只说“repo”，助手会默认你指的是 Git 仓库。
• 创建一个新的 Git 提交来记录助手所做的更改——通常用 git commit -m "提交信息" 命令。
• 为 GitHub 配置你的仓库。你需要先在 github.com/new 创建新仓库，并配置你的机器以连接 GitHub。
• 或者直接说“最近改动”或“最后三次提交”。

这是开启新编程助手会话的好方法。让助手查看最近改动，它会运行 git log，瞬间就能把近期工作详情——包括修改的代码和描述它们的提交信息——加载到上下文中。

这样“播种”会话后，你就可以直接讨论那段代码了：建议额外修复、询问工作原理，或者提出基于现有工作的下一步改动。

• 在主分支上运行此命令，从远程仓库获取其他人的贡献；或者在分支上运行，以集成主分支的最新更改。

合并更改有多种方式，包括合并（Merge）、变基（Rebase）、压缩（Squash）或快进（Fast-Forward）。记不清细节也没关系：

助手很擅长解释不同合并策略的优缺点，而且 Git 里的一切操作都可以撤销，尝试新方法风险很低。

• 这个通用提示词我出人意料地经常用！这是最近一个例子，它帮我修复了一个因合并冲突而失败的 cherry-pick 操作。

解决复杂问题

用 Git 很容易陷入混乱，比如拉取（Pull）或变基（Rebase）命令导致合并冲突，或者不小心把不该加的东西放进了暂存区。

以前，理清这些乱局是最耗时费力的 Git 工作。现在不用了！编程助手能处理最复杂的合并冲突，推理新代码的意图，决定保留什么、如何合并冲突的更改。如果你的代码有自动化测试（应该有），助手可以在最终完成合并前确保测试通过。

• 如果你丢失了之前提交过（或用 git stash 保存过）的代码，助手很可能帮你找回来。

Git 有个叫 reflog 的机制，经常能捕获未提交到永久分支的代码细节。助手可以搜索这个，也能搜索其他分支。

直接告诉它们要找什么，看它们深入挖掘就行。

用 bisect 精准调试

Git bisect 是 Git 工具库中最强大的调试工具之一，但学习曲线相对陡峭，常让开发者望而却步。

运行 bisect 操作时，你需要提供一个测试条件和一个起止提交范围。Git 会执行二分搜索，找出最早导致测试条件失败的提交。

这能高效回答“这个 bug 最初是什么引起的”这个问题。唯一的缺点是需要用 Git bisect 能执行的格式表达 bug 测试条件。

编程助手能帮你处理这些样板代码。这让 Git bisect 从一个偶尔使用的工具，升级为你随时可以调用的利器——只要你对软件的历史行为感到好奇。

重写历史

现在来点有趣的高级操作。

Git 仓库的提交历史不是固定的。数据毕竟只是磁盘上的文件（藏在隐藏的 .git/ 目录里），Git 本身也提供了修改历史的工具。

别把 Git 历史看作实际发生事情的永久记录——把它当成精心撰写的、描述软件项目演进的故事。

这个故事是辅助未来开发的工具。永久记录错误和已放弃的方向有时有用，但仓库作者可以做出编辑决策：保留什么、如何最好地捕捉那段历史。

编程助手非常擅长使用 Git 的高级历史重写功能。

撤销或重写提交

提交代码后又后悔的情况很常见——比如发现包含了不该加的文件。Git 的解决方法是 git reset --soft HEAD~1。我以前从来记不住这个命令，现在不用记了！

你也可以对提交进行更精细的“手术”——比如重写提交以移除单个文件。

助手能重写提交信息，也能把多个提交合并成单个单元。

我发现前沿模型通常对提交信息有很好的品味。我以前坚持自己写，但现在接受了它们产出的质量通常足够好，甚至常常比我写得更好。

从旧仓库碎片构建新仓库

我经常用的一招是：从大仓库中提取代码到新仓库，同时保留那段代码的关键历史。

一个常见例子是提取库。我可能在项目中构建了一些类和函数，后来意识到它们更适合作为独立可复用的代码库。

这类操作以前很复杂，大多数开发者会选择创建脱离旧提交历史的新副本。现在我们不用将就了！