如今，几乎所有版本控制系统都支持分支，即源于一个中央代码库的独立工作线。根据您的版本控制系统，主分支可能被称为主线、默认分支或主干。开发人员可以从主代码行创建自己的分支，并与其一起独立工作。
为什么要在分支上花心思？
分支允许开发人员团队在一个中央代码库中轻松协作。开发人员创建分支时，版本控制系统将在该时间点创建代码库的副本。对分支的更改不会影响团队中的其他开发人员。显然，这是一件好事，因为正在开发的功能可能会造成不稳定性，如果所有工作都在主代码行上进行，那会造成很大的干扰。但是无需将分支放置于单独隔离的环境中。开发人员可以轻松地从其他开发人员那里提取更改，以协作开发功能，并确保他们的私有分支不会与主分支相差太远。
分支不仅有利于功能工作。分支可以使团队免受重要的架构更改（如更新框架、通用库等）的影响。
敏捷团队的三种分支策略
分支模型通常因团队而异，并且软件界对此一直争论不休。一个重要的主题是，在合并回主分支之前，应该在分支中保留多少工作。
发布分支
发布分支是指发布完全包含在分支中的想法。这意味着在开发周期的后期，发布经理将从主分支（例如“1.1 开发分支”）创建一个分支。1.1 版本的所有更改都需要应用两次：一次应用于 1.1 分支，然后应用到主代码行。使用两个分支对团队来说是额外的工作，很容易忘记合并到两个分支。发布分支可能笨拙且难以管理，因为很多人在同一个分支上工作。我们都经历过不得不在一个分支上合并许多不同更改的痛苦。如果您必须创建发布分支，请尽可能接近实际发布版本创建分支。
发布分支是支持市场上版本化软件的重要组成部分。单个产品可能有多个发布分支（例如 1.1、1.2、2.0）来支持持续开发。请记住，早期版本（即 1.1）中的更改可能需要合并到更高版本的分支（即 1.2、2.0）中。请查看下方的在线研讨会，详细了解如何使用 Git 管理发布分支。
功能分支
功能分支通常与功能标记相结合，即在产品中启用或禁用功能的“开关”。这样可以轻松将代码部署到主分支中并控制该功能的激活时间，从而在功能向最终用户公开之前就能轻松初始部署代码。
功能标记的另一个好处是，代码可以保留在内部版本中，但在开发期间处于非活动状态。如果启用该功能时出现问题，系统管理员可以恢复功能标志并恢复到已知的良好状态，而不必部署新版本。
任务分支
在 Atlassian，我们专注于按任务创建分支的工作流。每个组织都有一种自然的方式，可以在事务跟踪器（如 Jira）中将工作分解为多项单独的任务。然后，事务将成为团队该工作的中心联系点。任务分支（也称为事务分支）功能直接将这些事务与源代码联系起来。每个事务都在自己的分支上实现，分支名称中包含事务关键字。很容易就能看出哪个代码实现了哪个事务：只需在分支名称中查找事务关键字即可。有了此等透明度，可以更轻松地将特定更改应用于主分支或任何长期运行的旧发布分支。
由于敏捷开发以用户故事为中心，因此任务分支与敏捷开发配合得很好。每个用户故事（或错误修复）都存在于自己的分支中，因此可以轻松查看哪些事务正在进行中，哪些已准备好发布。
现在来看看分支的邪恶双胞胎：合并
我们都经历过尝试将多个分支整合到一个合理的解决方案中的痛苦。传统上，像 Subversion 这样的集中式版本控制系统使合并成为一项非常困难的操作。但是，Git 和 Mercurial 等较新的版本控制系统采用了不同的方法来跟踪位于不同分支上的文件版本。
分支往往较为短暂，因此更容易合并，并且在整个代码库中更加灵活。在作为持续集成 (CI) 的一部分经常自动合并分支的能力与短期分支仅包含较少更改这一事实之间，对于使用 Git 和 Mercurial 的团队来说，“合并地狱”已成为过去。
这就是任务分支如此出色的原因！
验证、验证、验证
版本控制系统只能影响合并结果。自动化测试和持续集成也至关重要。大多数 CI 服务器可以自动对新分支进行测试，从而大大减少上游最终合并时的“意外”次数，并有助于保持主代码行的稳定。
