Git 分支与合并

分支让您可以在同一个项目中并行开展多条工作线，互不干扰。读完本文，您将了解分支是什么、有什么用，并学会创建和切换分支、合并更改，以及借助 IDE 工具从容地解决合并冲突。这些基础知识也能帮助您理解 Claude Code 在独立分支中操作 repository 时做了什么。

示例和界面截图基于 JetBrains IDE；操作名称和位置可能因您使用的版本而异。练习时请使用单独的练习 repository。在实际项目中，请遵循项目自身关于分支、提交和推送更改的规则。

分支是什么，为什么要用分支

分支是某条独立 commit 线的名称。创建分支不会复制项目文件夹，也不会保存尚未 commit 的文件。在普通工作目录中切换分支时，Git 会根据所选分支切换文件；未完成的更改可能会随您一起切换，也可能导致切换失败。

从主分支 main 分出新的 feature/new-idea 分支，用于独立开发。工作完成后，再将它合并回 main。

假设您想大幅改动项目，或尝试一项有风险的实验。没有 Git 的话，您会怎么做？很可能是把整个项目复制到一个新文件夹里，然后在那里操作。结果满意，就把更改移回主文件夹；不满意，删掉副本就行。

用副本来理解不同的工作方案很直观，但从技术上说，分支是指向某个 commit 的指针。我们用一本书来举例：

1. 您有一份完成的手稿（这就是主分支 main）；
2. 您想另写一个结尾（创建一个新分支，例如 feature/new-idea）；
3. 您写新结尾，不改动手稿的正文（在新分支中工作）；
4. 如果新结尾更合适，就用它替换旧结尾（通过 merge 合并分支）；
5. 带着旧结尾的草稿不再需要，可以删掉（删除分支）。

创建分支并在其中工作

步骤 1. 打开分支管理菜单。

主工具栏上、项目名称旁边有一个显示当前分支名称的小组件（默认是 main）。点击它，然后选择 + New Branch。

步骤 2. 为新分支命名。

比较好的做法是根据要完成的工作给分支命名。例如：feature/add-usage-examples。

如果创建时勾选了 Checkout branch，IDE 就会切换到新分支。开始编辑文件前，请先在小组件中确认分支名称。

步骤 3. 修改并 commit。

在 README.md 中添加一个使用示例小节。检查更改，然后照常执行 commit：新分支的历史中就会出现保存下来的快照。

切换分支

包含使用示例的更改已经稳妥地保存在 feature/add-usage-examples 分支中。现在回到主分支 main 看看那边的情况。

步骤 1. 再次点击左上角显示当前分支名称的小组件。

步骤 2. 在 Local 或 Recent 列表中选择 main 分支，然后在弹出的子菜单中点击 Checkout。

步骤 3. 检查结果。

切换完成后，打开 README.md。您会发现里面没有使用示例小节，因为它还在另一个分支中。这样，您就能开发新功能，而不影响 main 分支中的稳定版本。

合并分支

merge 会将选定分支的历史合并到当前分支。如果分支创建后 main 没有继续前进，就可以 fast-forward：main 会直接移到 C3，不产生新的 commit。如果两条开发线已经分开，普通合并会创建一个有两个父 commit 的 merge commit。

在这个线性示例中，main 可以直接移到 C3。feature/add-usage-examples 分支此时也指向 C3；合并时不需要删除它。

现在，您已经在 feature/add-usage-examples 分支中完成了工作，接下来要把这些更改合并到主项目中。

步骤 1. 切换到目标分支。

请确认您当前所在的分支正是要接收更改的分支。本例中是 main。

步骤 2. 执行合并。

再次点击分支管理小组件。在列表中选择要从中取出更改的分支（feature/add-usage-examples），然后在子菜单中选择 Merge 'feature/add-usage-examples' into 'main'。

步骤 3. 检查结果。

现在，main 分支中的 README.md 已经包含新的示例小节。您已成功将自己的工作合并到项目主线上。

合并冲突

冲突表示 Git 无法自动合并更改。常见情况是同一行被分别修改；也可能是在一个分支中删除文件、在另一个分支中修改该文件。具体如何处理，要根据预期结果决定。

这时，IDE（CLion 或 IntelliJ IDEA）的内置工具就派上用场了。在终端里解决冲突并不轻松，而内置的三方合并工具（3-way merge）能把过程展示得清楚、直观。

两个分支都在共同祖先 C1 之后有了新的 commit。历史分叉本身不一定会产生冲突；只有 Git 无法自动整合更改时才会出现冲突。下面的练习会用不同文本替换同一行。

我们来模拟一次冲突：

1. 请确认您位于 main 分支，并且 Commit 窗口中没有尚未 commit 的更改或新文件；
2. 创建新分支 feature/new-title，但暂时不要切换到该分支。确认 Checkout branch 复选框未选中；
3. 留在 main 分支，将 README.md 的第一行改为 "我的精彩项目"，然后执行 commit；
4. 切换到 feature/new-title 分支。您会看到，README.md 的第一行仍是旧内容，因为这就是创建分支时的文件状态。将同一行改为 "我的超级项目"，然后执行 commit；
5. 切回 main 分支，并与 feature/new-title 执行合并。

现在，Git 会发现两段历史都修改了同一处内容，并打开冲突解决窗口（Merge Conflicts）。

点击 Merge 按钮，打开冲突解决工具。界面中会显示：

• 左侧（Your changes） - 当前分支中的文件版本，也就是接收更改的分支 main；
• 右侧（Changes from branch） - 正在合入的分支中的文件版本；
• 中间（Result） - 您需要手动整理出的最终文件版本。

点击箭头 >> 或 <<，即可完整采用其中一个版本；也可以点击叉号取消。您还可以直接在中间面板中输入正确的文本。

检查中间面板中的最终结果，然后点击 Apply 或相应的完成按钮。接着查看 Git 状态：如果合并尚未 commit，请通过 IDE 执行 commit。解决文本冲突和完成 merge 是两个不同的步骤。最后检查代码运行情况。

为什么有时不会出现冲突

如果练习中没有出现冲突，请检查第二个分支是从哪个 commit 创建的，以及双方是否确实用不同内容替换了同一行。即使分支历史已经分开，Git 也能自动合并彼此兼容的更改。另一种情况是线性历史，可以进行 fast-forward：

例如：

1. main 中有一个 commit（假设是 C1）；
2. 您在 main 中创建一个新 commit，内容为 "我的精彩项目"。此时 main 指向 commit C2；
3. 从 main 当前的位置创建 feature/new-title 分支，因此新分支也从 commit C2 开始；
4. 您在 feature/new-title 中创建一个内容为 "我的超级项目" 的 commit。该分支向前推进并指向 commit C3；
5. 切回仍指向 commit C2 的 main，并合并 feature/new-title。

Git 会发现 main 是 feature/new-title 的直接祖先：您在另一个分支工作期间，main 没有新增 commit。因此，Git 只需将 main 的指针直接移到 commit C3，不会产生冲突。

main 的历史沿着 feature/new-title 继续向前，没有发生分叉，所以 Git 只需将 main 向前移动，不会出现冲突。

查看更改历史

查看项目历史有助于您更好地了解项目中的变化。

打开 Git 工具窗口（通常是 IDE 左侧栏或窗口底部的图标），然后选择 Git 工具栏中的 Log 或 Show Git Log 标签。您会看到所有分支和 commit 的图形化历史记录，可以直观地追踪分支从哪里分出，以及在哪里合并。

点击任意 commit，即可查看其中包含哪些更改，以及由谁在何时创建。这就像是代码的时光机。

与 Claude Code 配合时的工作方式

了解分支后，您就更容易看懂 Claude Code 在 repository 中执行的操作。它会利用这项技术为您完成一些工作，以下是值得留意的地方：

• 如果任务和项目规则要求这样做，它会创建一个独立分支；
• 在关键节点提议执行 commit - 您检查 diff，再决定接受还是修改；
• 帮助您找到需要的已保存 commit，并结合未 commit 的更改选择恢复方式；
• 遇到合并冲突时，它可能会请您协助 - 冲突仍可通过同一个 IDE 工具解决；
• 它也能创建并评论 pull request（PR，即将一个分支合入主分支的提议，例如通过 GitHub CLI）。

上一篇：Git 日常工作流程 · 下一篇：Pull request：从创建到合并