安全的试验：分支操作

1. 什么是分支以及为什么需要它们？

在 Git 中使用 branches 是版本管理的关键点之一，允许在同一个仓库中并行进行多条开发线。分支让 Git 成为一个强大的协作、试验和管理项目不同版本的工具。

            gitGraph
            commit id: "Initial setup"
            commit id: "Add base features"
            branch feature/new-idea
            checkout feature/new-idea
            commit id: "Implement new logic"
            commit id: "Refactor the logic"
            checkout main
            commit id: "Urgent bugfix on main"
            merge feature/new-idea
            commit id: "Prepare for release"
        

想象你想在项目里做大改动或做个有风险的试验。没有 Git 的话你会怎么做？很可能把整个项目复制到新文件夹然后在那儿工作。如果结果满意——把改动搬回主文件夹；不行就删掉副本。

Git 的分支也是这个思路，但更优雅。用写书来举例：

1. 你有一本完成的手稿（那就是你的主分支 main）。
2. 你想写另一个结局（创建新分支，比如 feature/new-idea）。
3. 你在新分支写新的结局，不影响主手稿的正文（在新分支工作）。
4. 如果新结局更好，你就用它替换旧的（做分支合并 — merge）。
5. 不需要的草稿可以删除（删除分支）。

2. 创建新分支并在上面工作

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

IDE 顶部面板有个小部件显示当前分支名（默认是 main）。点它，然后选择 + New Branch。

步骤 2. 新分支的名字。

好习惯是根据任务给分支命名。例如 feature/add-usage-examples。

创建分支后 IDE 会自动切换到它。你会在同一小部件里看到新的分支名。

步骤 3. 做改动并提交（commit）。

现在你在自己的“沙盒”里。我们来给 README.md 文件加一个包含使用示例的新章节。做完改动后像上一讲学到的那样做 commit。

3. 在分支间切换

带有使用示例的改动现在安全地保存在分支 feature/add-usage-examples。我们回到主分支 main 看看那边是什么情况。

步骤 1. 再次点击显示当前分支名的小部件。

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

步骤 3. 检查结果。

切换后打开 README.md。你会发现使用示例的章节不在这里！它留在了另一个分支。所以你可以在不影响主分支稳定版本的情况下开发新功能。

4. 分支合并（Merge）

命令 merge 会把分支 feature/add-examples（在本例中是提交 C3）里的所有提交合并到当前分支 main，并创建一个新的合并提交。

            gitGraph
            commit id: "C1"
            commit id: "C2"
            branch feature/add-examples
            checkout feature/add-examples
            commit id: "C3: Add new section"
            checkout main
            merge feature/add-examples
        

好了，你在分支 feature/add-usage-examples 完成了任务，想把这些改动加到主项目里。

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

确认你在想把改动合入的那个分支。这里是 main。

步骤 2. 执行合并。

再次点击分支管理小部件。在列表里选中你想从中取改动的分支（feature/add-usage-examples），在子菜单选择把 feature/add-usage-examples 合并到 main（Merge）。

步骤 3. 检查结果。

现在在 main 的 README.md 中出现了你新增的使用示例章节。你已成功把工作合并到主版本！

5. 合并冲突：别怕，这很正常！

有时合并分支会出现 冲突。当两个分支在同一个文件的同一行都做了修改时就会发生。Git 无法自动判断哪个版本是对的，会请你介入解决。

            gitGraph
            commit id: "C1: Common base"
            branch feature/new-title
            checkout main
            commit id: "C2: Change in main"
            checkout feature/new-title
            commit id: "C3: Change in feature"
        

我们来模拟一个冲突：

1. 确保你在分支 main，并且没有未保存的改动。
2. 现在立刻创建新分支 feature/new-title，但先别切换过去。确认 Checkout branch 的勾是取消的。
3. 仍然在 main，把 README.md 第一行改成 "My Awesome Project" 并做 commit。
4. 切到分支 feature/new-title。你会看到 README.md 的第一行还是旧的：这是分支创建时的文件状态。把同一行改成 "My Super Project" 并做 commit。
5. 回到 main 并把 feature/new-title 合并进来。

现在 Git 会看到两条从共同祖先分出的不同历史，并且两边都改了同一行，所以 Git 不能自动决定哪个版本对，它会显示一个用于解决冲突的窗口。

Merge Revision

这里你会看到：

• 左边 (Your changes): 来自你当前分支（main）的文件版本。
• 右边 (Changes from branch...): 来自要合并进来的分支的文件版本。
• 中间 (Result): 你需要组装的最终文件版本。

你可以点那些箭头 >> 或 << 来接收整块内容的某个版本。

当中间面板的结果让你满意时，点 Apply。IDE 会自动创建合并提交，冲突就解决了。

为什么有时候不会出现冲突？

可能出现这种情况：你按步骤操作但没有冲突。通常是因为 Git 能做 fast-forward merge，也就是某个分支的历史只是另一条分支的延续。要保证出现冲突，分支历史必须从共同祖先向不同方向分叉。

示例：

1. 在 main 上有一个提交（假设是 C1）。
2. 你在 main 做了一个新提交，内容是 "My Awesome Project"。现在 main 指向提交 C2（main -> C1 -> C2）。
3. 你从当前的 main 创建了分支 feature/new-title。新分支也从提交 C2 开始。
4. 你在 feature/new-title 做了一个提交，内容是 "My Super Project"。这个分支向前走到提交 C3（feature/new-title -> C1 -> C2 -> C3）。
5. 你回到还停在 C2 的 main，并命令合并 feature/new-title。

Git 看着这情况，发现 main 是 feature/new-title 的直接祖先。main 在你在另一个分支工作时没有新提交。Git 会认为：“这很简单，把 main 快进到 C3 就行，没冲突”。于是它把 main 的指针直接移动到 C3。

            gitGraph
            commit id: "C1"
            commit id: "C2"
            branch feature/new-title
            checkout feature/new-title
            commit id: "C3"
            checkout main
            merge feature/new-title
        

6. 查看变更历史

为了更好理解项目里发生了什么，查看历史是很有用的。

打开 IDE 底部的 Git 标签，选择 Log。你会看到所有分支和提交的图形表示。这样能直观地追踪出哪个分支从哪儿分出来，哪里合并过。

在这里你可以点击任意提交，查看它包含了哪些改动，谁在什么时候做的。它就是代码的时间机器！