3.4 Git 分支 - 分支工作流

因为 Git 使用简单的三方合并，所以在很长一段时间内多次将一个分支合并到另一个分支通常很容易。这意味着你可以有几个总是打开的分支，并将它们用于开发周期的不同阶段；你可以定期将其中一些合并到其他分支中。

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

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

通常更容易将它们视为工作“筒仓”，其中一组提交在完全测试后会“升级”到更稳定的筒仓。

你可以对多个稳定级别重复此操作。一些大型项目还拥有一个 proposed 或 pu（proposed updates，提议的更新）分支，它集成了可能尚未准备好进入 next 或 master 分支的分支。其思想是你的分支处于不同的稳定性级别；当它们达到更稳定的级别时，它们会被合并到它们上面的分支中。同样，拥有多个长期分支并非必要，但通常很有帮助，尤其是在处理非常大型或复杂的项目时。

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

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

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

现在，假设你决定你最喜欢解决问题的第二种方案（iss91v2）；你将 dumbidea 分支展示给你的同事，结果发现它是个天才的想法。你可以丢弃最初的 iss91 分支（失去提交 C5 和 C6），然后合并其他两个分支。你的历史记录将看起来像这样：

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

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