3.4 Git 分支 - 分支工作流

由于 Git 使用简单的三方合并，因此在很长一段时间内将一个分支多次合并到另一个分支通常很容易实现。这意味着你可以拥有多个始终处于开放状态的分支，并将它们用于开发周期的不同阶段；你可以定期将其中一些分支合并到其他分支中。

许多 Git 开发者采用一种拥抱这种方法的工作流，例如他们的 master 分支中只包含完全稳定的代码——可能只是已经发布或将要发布的代码。他们还有另一个并行的分支，名为 develop 或 next，他们从这个分支开始工作或用于测试稳定性——它不一定总是稳定的，但只要它达到稳定状态，就可以合并到 master 中。它用于在主题分支（短期分支，如你之前的 iss53 分支）准备就绪时将其拉入，以确保它们通过所有测试并且不引入错误。

实际上，我们谈论的是指针在你所做的提交线上向上移动。稳定分支在你的提交历史中靠下，而最前沿的分支则在历史中靠上。

通常更容易将它们视为工作“筒仓”（silo），当一系列提交经过充分测试后，就会“毕业”到更稳定的筒仓中。

你可以持续进行这种多级稳定性划分。一些大型项目还拥有一个 proposed 或 pu（proposed updates，提议更新）分支，该分支集成了可能尚未准备好进入 next 或 master 分支的子分支。其思想是你的分支处于不同的稳定性级别；当它们达到更稳定的级别时，就会合并到其上方的分支中。再次强调，拥有多个长期分支并非必需，但通常很有帮助，特别是当你处理非常大型或复杂的项目时。

然而，主题分支在任何规模的项目中都很有用。主题分支是一种短期分支，你创建它并用于单个特定功能或相关工作。这可能是你以前从未在版本控制系统（VCS）中做过的事情，因为通常创建和合并分支的成本太高。但在 Git 中，每天创建、工作、合并和删除分支是司空见惯的。

你在上一节中看到了你创建的 iss53 和 hotfix 分支。你在它们上面做了几次提交，并在合并到主分支后直接删除了它们。这种技术允许你快速彻底地切换上下文——因为你的工作被分离到“筒仓”中，其中该分支中的所有更改都与该主题相关，因此在代码审查等过程中更容易看出发生了什么。你可以将这些更改保留数分钟、数天或数月，并在它们准备就绪时将其合并，无论它们创建或工作的顺序如何。

考虑一个例子：你在 master 分支上做了一些工作，然后为了一个问题（iss91）创建了一个新分支，工作了一段时间，接着从第二个分支（iss91v2）再次创建分支以尝试另一种处理相同问题的方法，然后回到你的 master 分支并工作了一段时间，再从那里创建一个你不确定是否是个好主意的工作（dumbidea 分支）。你的提交历史将看起来像这样：

现在，假设你决定你最喜欢解决问题的第二个方案（iss91v2）；并且你向同事展示了 dumbidea 分支，结果证明它是个天才的想法。你可以抛弃原始的 iss91 分支（丢失提交 C5 和 C6），并合并其他两个分支。你的历史将看起来像这样：

我们将在分布式 Git 中详细介绍你的 Git 项目可能存在的各种工作流，因此在决定下一个项目将使用哪种分支方案之前，请务必阅读该章节。

重要的是要记住，当你进行所有这些操作时，这些分支是完全本地的。当你进行分支和合并时，所有操作都只在你的 Git 仓库中进行——没有与服务器的通信。