3.4 Git 分支 - 分支工作流程

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

许多 Git 开发人员都采用这种工作流程，例如，只将完全稳定的代码保存在其 master 分支中 — 可能是已发布或即将发布的代码。他们还有一个名为 develop 或 next 的并行分支，他们从中工作或用于测试稳定性 — 它不一定总是稳定的，但只要它达到稳定状态，就可以合并到 master 中。当主题分支（短期分支，例如您之前的 iss53 分支）准备好时，就可以将其合并进来，以确保它们通过所有测试并且不会引入 bug。

实际上，我们讨论的是指向您正在进行的提交的指针。稳定分支在您的提交历史中位于较靠下的位置，而最新的分支则位于较靠上的位置。

通常更容易将它们视为工作隔离区，当一组提交经过充分测试后，它们就会进入更稳定的隔离区。

您可以为多个稳定性级别重复此操作。一些大型项目还有一个 proposed 或 pu（proposed updates）分支，其中包含尚未准备好合并到 next 或 master 分支的已集成分支。其理念是您的分支处于不同的稳定性级别；当它们达到更稳定的级别时，就会合并到其上方的分支中。同样，并非必须拥有多个长期分支，但它通常很有帮助，尤其是在处理非常大或复杂的项目时。

然而，主题分支对任何规模的项目都很有用。主题分支是一个短期分支，您创建它并将其用于单个特定功能或相关工作。这可能是您以前从未对版本控制系统做过的事情，因为创建和合并分支通常成本很高。但在 Git 中，一天内创建、处理、合并和删除分支多次是很常见的。

在上一节中，您已经看到过您创建的 iss53 和 hotfix 分支。您在上面进行了几次提交，并在合并到主分支后立即删除了它们。这种技术可以让您快速而全面地切换上下文 — 因为您的工作被分成了隔离区，该分支中的所有更改都与该主题相关，因此更容易在代码审查等过程中了解发生了什么。您可以将更改保留在那里几分钟、几天或几个月，并在准备好时将其合并，而无论它们创建或处理的顺序如何。

考虑一个例子：您正在进行一些工作（在 master 上），然后为某个问题创建一个分支（iss91），在该分支上工作一段时间，然后从第二个分支再次分支以尝试处理同一问题的另一种方法（iss91v2），然后回到 master 分支并在此处工作一段时间，然后再次从此处分支以执行一些您不确定是否是好主意的操作（dumbidea 分支）。您的提交历史将如下所示：

现在，假设您决定最喜欢第二个解决方案（iss91v2）；您将 dumbidea 分支展示给同事，结果发现它是个天才的想法。您可以丢弃原始的 iss91 分支（丢失提交 C5 和 C6），然后合并另外两个。您的历史记录将如下所示：

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

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