3.4 Git 分支 - 分支工作流

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

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

实际上，我们讨论的是指针沿着你提交的路线移动。稳定的分支在提交历史的下游，而前沿（bleeding-edge）分支则在历史的上游。

通常将它们视为工作“孤岛”（silo）会更容易理解，即一组提交在经过充分测试后，被提升到更稳定的孤岛中。

你可以为不同级别的稳定性持续进行此操作。一些大型项目还拥有一个 proposed 或 pu（拟议更新）分支，其中集成了可能尚未准备好进入 next 或 master 分支的分支。其理念是你的分支处于不同的稳定性级别；当它们达到更稳定的级别时，它们会被合并到上层分支中。再次强调，拥有多个长期分支并非必要，但通常很有帮助，特别是在处理非常大型或复杂的项目时。

然而，主题分支在任何规模的项目中都很有用。主题分支是你为单个特定功能或相关工作创建和使用的短命分支。这可能是你以前在使用 VCS 时从未做过的事情，因为创建和合并分支通常代价太高。但在 Git 中，每天创建、使用、合并和删除分支多次是很常见的。

你在上一节中看到的 iss53 和 hotfix 分支就是这样。你在它们上面做了几次提交，并在将它们合并到主分支后立即删除了它们。这种技术使你能够快速且彻底地进行上下文切换——因为你的工作被隔离在孤岛中，该分支中的所有更改都与该主题相关，因此在代码审查等过程中更容易看出发生了什么。你可以将更改保留几分钟、几天或几个月，并在准备好后合并它们，而无需考虑它们创建或工作的顺序。

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

现在，假设你认为解决问题的第二个方案（iss91v2）最好；而且你向同事展示了 dumbidea 分支，结果发现它是个天才想法。你可以丢弃最初的 iss91 分支（丢失提交 C5 和 C6）并合并另外两个。你的历史记录随后看起来像这样

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

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