分支工作流
现在已经掌握了分支和合并的基础知识，可以或应该如何使用它们？在本节中，我们将介绍一些常见的工作流程，这种轻量级的分支使得这些工作流程成为可能，因此我们可以决定是否要将它们纳入到自己的开发周期中。
长期运行的分支
由于Git使用简单的三路合并，因此在长时间内多次从一个分支合并到另一个分支通常很容易。这意味着可以拥有几个始终开放的分支，用于开发周期的不同阶段；可以定期将其中一些分支合并到其他分支中。
许多Git开发人员采用这种方法的工作流程，例如，在他们的主分支中只有完全稳定的代码 - 可能只有已经发布或将要发布的代码。他们有另一个名为develop或next的平行分支，从中进行工作或用于测试稳定性 - 它不一定总是稳定的，但每当它达到稳定状态时，就可以合并到主分支中。它用于在准备就绪时拉取主题分支（短期存在的分支，例如之前的iss53分支），以确保它们通过所有测试并且不引入错误。
实际上，我们谈论的是指针在正在进行的提交历史线上移动。稳定的分支位于提交历史线的下游，而最新的分支则位于历史的上游。
通常更容易将它们视为工作隔间，其中一组提交在完全测试通过后会升级到更稳定的隔间。
可以针对多个稳定级别继续执行此操作。一些较大的项目还可能有一个proposed或pu（提议更新）分支，其中包含可能尚未准备好进入下一个或主分支的集成分支。这个想法是，当前分支处于不同的稳定级别；当它们达到更稳定的水平时，它们将合并到它们上面的分支中。再次强调，拥有多个长期运行的分支并不是必需的，但通常很有帮助，特别是在处理非常大型或复杂的项目时。
主题分支
然而，在任何大小的项目中，主题分支都是有用的。主题分支是创建并用于单个特定功能或相关工作的短期存在的分支。这是以前可能从未在版本控制系统中执行过的操作，因为创建和合并分支通常成本过高。但在Git中，一天中创建、处理、合并和删除分支几次是很常见的。
在前面篇章中使用iss53和hotfix分支就看到了这一点。在这些分支上进行了一些提交，然后在将它们合并到主分支后直接删除了它们。这种技术允许快速而完全地进行上下文切换 - 因为工作被分隔成了各自的隔间，该分支中的所有更改都与该主题相关，因此在代码审查等过程中更容易看到发生了什么。可以将更改保留在那里数分钟、数天或数月，并在准备好时合并它们，而不管它们创建或工作的顺序如何。
考虑一个例子，在主分支上进行一些工作，然后切换分支到一个问题分支（iss91）上进行一些工作，然后再切换分支到另一个分支上尝试另一种处理相同事物的方式（iss91v2），然后回到主分支并在那里进行一段时间的工作，然后在那里分支出来做一些不确定是否是一个好主意的工作（dumbidea分支）。上述提交历史将看起来像这样：
现在，假设最喜欢第二个解决方案（iss91v2）；并且向同事展示了dumbidea分支，结果证明它是个天才点子。可以丢弃原始的iss91分支（丢失提交C5和C6），并合并另外两个分支。操作历史看起来像这样：
重要的是要记住，在进行所有这些操作时，这些分支完全是本地的。在切分支和合并时，所有操作都仅在本地git存储库中进行 - 与服务器没有任何通信。