优化分支冲突的关键策略

引言

在团队协作开发中，有时候会出现多个人同时在一个代码仓库中进行开发。如果这时候采用了分支模式（而不是主干模式）的话，很容易造成分支合并冲突。这种冲突不仅会降低协作效率，同时会影响开发积极性。本文将介绍一些关键的优化策略，帮助开发人员提高分支合并效率，减少分支冲突，为团队协作带来更好的体验和产品交付效率。

图 1：分支合并冲突

问题描述

让我们考虑一个多人协作且多分支并行开发时候常见的情况：十几个开发者，在同一个微服务的应用中都创建了分支进行并行开发，因为长时间内都没有发布和合并主干，在测试环境的部署中造成了极大的代码冲突。这时候，张三加入进来，想添加一个新特性，或者修复一个小 Bug，极可能出现为了在测试环境发布一个 5 分钟就能实现的特性，而不得不花费数小时，甚至几天时间去解决分支合并冲突的问题。

这种问题会带来极大的负面影响：

1. 开发体验非常糟糕；

2. 产品交付效率极大的降低，原本 5 分钟的需求被延长到数小时甚至数天；

3. 在一个复杂的项目场景中，存在多个任务间依赖，一项关键路径的任务推迟，会导致整个项目组十多人的任务都被推迟。

解决方案介绍

笔者最为推荐的解决方案是采用主干模式开发，可以避免分支合并冲突的困扰，但是考虑带这种模式对于开发团队的成熟度、基础架构和自动化测试要求较高，不在本文中重点讨论。感兴趣的可以移步到这两篇文章中查看：

1. Google Cloud 云架构中心文章：「DevOps 技术：主干开发」
   

2. 36氪技术文章：「Google 和腾讯为什么都采用主干开发模式？」
   

图 2：优化分支策略

如果在某个项目开发中，分支多、参与人员多的“两多”问题无法避免的话，可以通过减少分支数量、减少分支存活时长、减少分支内代码行数的方式来降低代码冲突带来的影响。

1. 制定规范

2. 分支创建时候有日期标识，如果是成熟的变更管理系统大概率自带该项特性；不符合规范的分支可以被归档；

3. 分支创建超过 1 个月：从测试（Testing）/预发布（Staging）的集成区退出，不参与集成发布；

4. 分支创建超过 6 个月：归档并删除该分支；

5. 建立清理机制

6. 由应用的负责人，或者指定其他的负责人，来执行该项规范，或者通过工具实现自动化执行；确保集成区的分支数量收敛、分支内的代码行数收敛；

7. 可以通过群或者邮件来通知相关人员，或者在达成共识情况下静默的或自动的执行，以降低沟通和执行成本；

8. 引入灰度开关（Feature Toggle）：要实行以上策略的话，必须有成熟且高效的灰度开关系统支撑，允许通过开关来控制一些尚未准备好全量发布的特性提前合并到主干中

9. 建立成熟且高效的灰度开关系统，允许通过用户、组织、部门、行业、地区、百分比等维度开启和关闭一些特性；

10. 通常情况下有用户维度的灰度即可，为开发、测试、产品经理等人员开启内测中的特性，针对其他用户关闭特性。以实现合并到主干中但是尚未完全准备好的功能特性不会被全量发布出去；

11. 在用户维度之外，可以根据实际需要选择组织、部门、行业、百分比等维度的灰度开关；

12. 如果期望在公司内部的员工可以访问内测中的特性，暂时不对外开放，可以引入 IP 维度灰度开关，仅对公司办公网 IP 开启；

13. 如果期望仅在测试环境（Testing）和预发布环境（Staging）开启内测中的特性，可以根据环境选择特性是否开启；

关于运行时灰度开关系统的介绍，可以参考 Martin Fowler 的技术文章：「Feature Toggles (aka Feature Flags)」。

实施步骤

1. 建立规范文档：详细描述分支管理规范，确保所有参与人员有权限访问，且能够随时找到该文档。例如将文档链接放在项目群公告中、放到发布系统中应用发布页面的公告中等地方；

2. 确定执行机制：选择合适的负责人来执行定期清理，或者开发定时清理的自动化任务；

3. 小范围沟通：选择关键人员，沟通该规范和机制的作用，确认可以有效解决大家遇到的问题，并在解决方案上达成共识，或者改进后达成共识；

4. 正式沟通和公布：组织会议，邀请所有相关人员参与，公布分支管理规范和机制，听取意见，得到支持；

5. 定时清理和归档：按照既定的规范，由指定的负责人定期清理和归档，或者采用工具自动化执行。

注意事项

1. 分支的存活时长（1 个月、6 个月等）可以不用照搬本文的提到时间约束，可以根据实际场景设置适合自己的分支存活时长；

2. 充分的沟通是成功的关键，所有的规范必须得到管理团队和协作人员的认可，而不是擅自发布和暴力执行。通过组织会议形式，让相关人员意识到解决该问题的必要性和带来的好处，并听从协作开发者的建议予以修正和改进；

总结

通过建立完善的分支合并和清理规范，并通过沟通得到团队的共识和支持，可以实现分支规模（数量、存活时长、分支内代码量）快速收敛，减少甚至避免了分支合并冲突。在一些密集开发和集成的应用中，可以极大的减少分支合并冲突的困扰，带来效率的提升，以及开发人员的开发体验。

参考资料

• Medium 上的技术文章：「How Chromium Works」，其中重点介绍了 No branches 和 Runtime switches

• 「Feature Toggles (aka Feature Flags)」
  

• Google Cloud 云架构中心文章：「DevOps 技术：主干开发」
  

• 36氪技术文章：「Google 和腾讯为什么都采用主干开发模式？」