当今几乎所有版本控制系统都支持分支 ---- 由中心代码库派生出来的独立工作路线。根据版本控制系统的不同，主分支可能被命名为mainline, default 或者trunk。开发者可以基于主分支创建自己的分支，以便在主分支之外独立开展工作。
分支策略为什么重要？
分支的存在可以让团队成员在同一个中心化的代码库中轻松进行协作。当开发者创建一个分支时，版本控制系统会在代码库的当前时间点创建一份拷贝。如此一来，分支中的变化就不会影响团队其他成员。这显然是一件好事，因为所有在开发中产生的代码变更都会带来不稳定性，所以假设开发过程中的变更都产生在主分支上，就会破坏主分支的稳定性。在分支上，开发者可以轻松使用pull命令更新其他开发者的代码变更以便协作，同时也保证自己的私有分支不会与主分支产生过大的偏离。
提示
分支不仅仅对于开发新功能有益，还可以用于将团队其他成员的功能代码与重要的架构变化隔离开。比如像升级框架，升级公共库这种较底层的架构变化。
三种适用于敏捷团队的分支策略
通常来说，分支模型在不同团队中都不会完全一样。在软件开发社区中，分支模型也一直是一个很有争议的话题。其中一个争议的关注点就是：一个主分支之外的分支，应该以多大的粒度进行规划。
发布分支策略
发布分支策略是指，一次计划发布的所有内容都包含在这个分支中。这就意味着在一次发布周期中的较晚时间点上，发布经理将会从主分支创建一个发布分支，比如叫做1.1DevelopmentBranch。于是接下来所有1.1版本需要发布的内容都需要进行至少两次合并：一次合并进1.1分支，另一次合并回主分支。这会带来两个问题：首先，维护两个分支对于开发团队来说就是额外的工作，并且也很容易忘记将发布变更再合并回主分支；其次，当有很多人在同一个（发布）分支上提交变更时，发布分支就会变得笨拙并且不易维护。我们应该都体会过所有人都向同一个分支合并代码变更的痛苦。如果你一定要采用发布分支策略，那么尽可能在距离实际发布状态近的时候创建发布分支。
请注意
发布分支策略在市场上广泛用于支持软件开发的版本管理。为了支持可持续的版本迭代，一个产品需要维护多个版本的发布分支（比如同时需要维护1.1，1.2，2.0）。在这种场景下必须要记得，将早发布版本的代码变更合并到晚发布的版本分支中去（比如在1.1版本中合并的代码变更，要记得同时合并入1.2和2.0版本中）
功能分支策略
功能分支通常会与功能标记（feature flag）同时使用。切换功能标记可以打开或者关闭产品中的某一个功能。这种方式可以赋予部署功能更大的灵活性，甚至可以让一个功能在还不需要暴露给用户的时候就先部署到线上。真正需要开启这个功能时，只需要切换flag即可。
提示
另外一个好处在于，当一个功能还未完全成熟时，其代码仍然可以留存在主分支中。当功能被打开时，通过监控或者灰度发布等能力观察到功能有误，系统管理员可以通过切换功能标记（feature flag）将线上版本回退到之前完全正常的旧版本。
任务分支策略
每个团队在开发前都会将问题分解为一个个独立的任务。此时，所有成员的关注点也随之被分解为如何解决这些独立的任务。如果团队使用jira来管理问题（比如将epic分解为一个一个jira issue），那么就可以通过建立与jira issue相关联的分支来进行协作。分支的名称包含jira issue的ticket key。通过查看分支名称，就能很方便地找到与该分支对应的issue。通过这种方式提高了分支与任务本身的关联度，便能轻松地决定如何对任务分支进行合并。
由于敏捷流程以用户故事为中心展开，任务分支策略可以很好地配合敏捷开发流程。每一个（jira上的）用户故事（或者bug修复）都有与之对应的代码分支，所以仅从分支名称就可以知道哪个分支正在进行中，哪个分支可以合并发布。
现在来认识一下分支的邪恶双胞胎：merge
我们都忍受过合并多个分支的痛苦。在以前，中心化的版本控制系统的合并流程令人痛苦，比如subversion。但是目前的版本控制系统采取了新的方式跟踪不同分支上文件的版本，而不是整个代码库的版本，比如Git或者Mercurial。
分支应具有简短的生命周期，以便更容易地合并回主分支，这对于整个代码库来说也更加灵活。更短的生命周期通常意味着分支内的代码变动更少，再加上持续集成系统帮助下赋予的高频率自动化的分支合并能力，“合并地狱”终于成为Git或者Mercurial使用者的过去式。
再三验证
更好的版本控制系统赋予工作流良好的分支管理方法。但是对于合并后的分支来说，自动化测试和持续集成同样重要。大多数CI服务会自动对新的分支代码运行测试代码，每一次提交都及时进行测试和代码质量检测，可以大幅降低最终合并到主分支时发生surprise的几率。工作流中的再三验证，确保了最终上线的主分支是稳定可靠的。
翻译自：https://www.atlassian.com/agile/software-development/branching
网友评论