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 存储库中完成——没有与服务器进行通信。