什么是敏捷团队分支策略

如今，几乎所有版本控制系统都支持分支，即源于一个中央代码库的独立工作线。根据您的版本控制系统，主分支可能被称为主线、默认分支或主干。开发人员可以从主代码行创建自己的分支，并在分支上独立开展工作。

为什么要在分支上花心思？

分支允许开发人员团队在一个中央代码库中轻松协作。开发人员创建分支时，版本控制系统将在该时间点创建代码库的副本。对分支的更改不会影响团队中的其他开发人员的工作。显然，这是一件好事，因为正在开发的功能可能会造成不稳定性，如果所有工作都在主代码行上进行，那会造成很大的干扰。目前，开发人员无需将分支放置于单独隔离的环境中也可以轻松地从其他开发人员那里提取更改代码，以协作完成开发功能的开发，并确保他们的私有分支不会与主分支相差太远。

Tips：

分支不仅有利于功能工作，还可以使团队免受重要的架构更改（如更新框架、通用库等）的影响。

敏捷团队的三种分支策略

分支模型通常因团队而异，并且软件界对此一直争论不休。其中一个大的争议主题是在合并回主分支之前应该在分支中保留多少工作。

发布分支

发布分支是指发布完全包含在分支中的想法。这意味着在开发周期的后期，研发负责人将从主分支（例如“1.1 开发分支”）创建一个分支。1.1 版本的所有更改都需要应用两次：一次应用于 1.1 分支，然后应用到主代码行。使用两个分支对团队来说是额外的工作，很容易忘记合并到两个分支。发布分支可能操作不便且难以管理，因为很多人在同一个分支上工作。我们都经历过不得不在一个分支上合并许多不同更改的痛苦。如果您必须创建发布分支，请尽可能接近实际发布版本创建分支。

Tips：

发布分支是支持市场上版本化软件的重要组成部分。单个产品可能有多个发布分支（例如 1.1、1.2、2.0）来支持持续开发。请记住，早期版本（即 1.1）中的更改可能需要合并到更高版本的分支（即 1.2、2.0）中。请查看下方的在线研讨会，详细了解如何使用 Git 管理发布分支。

功能分支

功能分支通常与功能标记相结合，即在产品中启用或禁用功能的“开关”。这样可以轻松将代码部署到主分支中并控制该功能的激活时间，从而在功能向最终用户公开之前就能轻松初始部署代码。

Tips：

功能标记的另一个好处是，代码可以保留在内部版本中，但在开发期间处于非活动状态。如果启用该功能时出现问题，系统管理员可以恢复功能标志并恢复到已知的良好状态，而不必部署新版本。

任务分支

在 PingCode，我们专注于按任务创建分支的工作流。每个组织都有一种自然的方式，可以在事务跟踪器中分解单个任务的工作。然后，事务将成为团队该工作的联系中心。任务分支，也称为事务分支，直接将这些事务与源代码联系起来。每个事务都在自己的分支上实现，分支名称中包含事务密钥。我们可以很容易看出哪个代码实现了哪个事务：只需在分支名称中查找事务密钥即可。有了这种透明度，可以更轻松地将特定更改应用于主分支或任何不再运行的旧发布分支。

由于敏捷开发以用户故事为中心，因此任务分支与敏捷开发在协作上配合得很好。每个用户故事（或缺陷修复）都存在于自己的分支中，因此可以轻松查看哪些事务正在进行中，哪些已准备好发布。