3.4 Git 分支 - 分支工作流程

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

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

实际上，我们讨论的是指针在您正在进行的提交线上移动。稳定的分支在您的提交历史中更靠下，而前沿分支在历史中更靠上。

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

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

但是，主题分支在任何规模的项目中都很有用。主题分支是一个短期的分支，您创建并用于单个特定功能或相关工作。这可能是您以前从未使用过 VCS 的操作，因为创建和合并分支通常成本过高。但在 Git 中，每天创建、处理、合并和删除分支很常见。

您在上节中看到了创建的iss53和hotfix分支。您在上面进行了一些提交，并在将其合并到主分支后直接删除了它们。此技术允许您快速且完整地切换上下文——因为您的工作被分隔成筒仓，其中该分支中的所有更改都与该主题有关，因此更容易查看代码审查等过程中发生了什么。您可以将更改保留几分钟、几天或几个月，并在准备好后合并它们，而不管它们创建或处理的顺序。

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

现在，假设您决定最喜欢问题的第二个解决方案（iss91v2）；并且您向同事展示了dumbidea分支，结果证明它很天才。您可以丢弃原始的iss91分支（丢失提交C5和C6）并合并其他两个分支。然后您的历史记录如下所示

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

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