Git 分支策略概述
在现代软件开发中，Git 已成为团队协作和版本管理的首选工具。而分支策略作为代码管理的核心部分，直接影响着团队开发效率、代码质量以及产品的交付速度。一套合理的分支策略，不仅能够帮助团队高效协作，还能确保代码集成与发布过程的规范性和可控性。
不同类型的软件项目（例如小型团队项目、大型企业级应用）和开发模式（如敏捷开发、DevOps）对分支策略的需求各有不同。因此，制定分支策略需要综合考虑多个因素，如团队规模、发布频率、项目架构、自动化能力以及人员技术水平等。
本篇文章探讨几种常见的Git 分支策略。
主干开发分支分支发布
优势：
- 只有一条主线分支，不需要在多条分支间切换。
- 在发布分支拉出之后，主干分支依然处于可集成状态，研发节奏可以保持在一个相对平稳的状态。
- 发布分支一般以版本号命名，清晰易懂，线上哪个版本出了问题，就在哪个分支上修复。
劣势：
1.它对主线分支的质量要求很高。如果主线分支出了问题，就会 block 所有开发团队的工作
2.它对团队协作的节奏要求很高。如果主线分支上的功能没有及时合入，但是业务方又坚持要在指定版本上线这个功能，这就会导致发布分支“难产”。甚至有些时候，会被迫允许部分未开发完成的功能在发布分支上继续开发，这会给发布分支的质量和稳定性造成很大的挑战。
3.在主线和发布分支并存期间，有可能会导致两边提交不同步的情况。比如，发布分支修复了一个线上问题，但是由于没有同步回主线，导致同样的问题在下一个版本中复现。测试出来的问题越多，这种情况出现的概率就越大，更不要说多版本并存的情况了
解决办法:
- 建立提交的准入门禁，不允许不符合质量标准的代码合入主线。
- 采用版本火车的方式，加快版本的迭代速度，功能“持票上车”，如果跟不上这个版本就随下个版本上线。另外，可以采用功能开关、热修复等手段，打破版本发布的固定节奏，以一种更加灵活的方式对外发布。
- 通过自动化手段扫描主线和发布分支的差异，建立一种规则。比如 Hotfix 必须主线和发布分支同时提交，或者发布分支上线后，由专人反向同步等。
分支开发主干发布
当开发接到一个task之后，会基于主干拉出一条feature分支，在feature分支上完成功能开发验证之后，通过 Merge request的方式发起合并请求，在评审通过后合入主干，并在主干完成功能的回归测试。
据特性和团队的实际情况，还可以进一步细分为两种情况：
- 每条特性分支以特性编号或需求编号命名，在这条分支上，只完成一个功能的开发；
- 以开发模块为单位，拉出一条长线的特性分支，并在这条分支上进行开发协作。
两者的区别就在于feature分支存活的周期，拉出时间越长，跟主干分支的差异就越大，分支合并回去的冲突也就越大。所以，对于长线模式来说，要么是模块拆分得比较清晰，不会有其他人动这块功能，要么就是保持同主干的频繁同步。随着需求拆分粒度的变小，短分支的方式其实更合适。
特性发布虽然看起来很好，但是有三个前置条件：
- 特性拆分得足够小
- 有强大的测试环境作支撑，可以满足灵活的特性组合验证需求
- 要有一套自动化的特性管理工具
优势：
- 分支开发相对比较独立，不会因为并行导致互相干扰
- 随着特性分支的流行，在这种模式下，分支成了特性天然的载体。一个特性所关联的所有代码可以保存在一条特性分支上，这为以特性为粒度进行发布的模式来说提供了一种新的可能性。也就是说，如果你想要发布哪个特性，就可以直接将特性分支合并到发布分支上，这就让某一个特性变得“可上可下”，而不是混在一大堆代码当中，想拆也拆不出来。
劣势：
- 非常考验团队特性拆分的能力。如果一个特性过大，会导致大量并行开发的分支存在，分支的集成周期拉长，潜在的冲突也会增多。另外，分支长期存在也会造成跟主线差异过大的问题。所以，特性的粒度和分支存活的周期是关键要素。根据经验来看，分支存活的周期一般不要超过一周。
- 对特性分支的命名规范要求很高。由于大量特性分支的拉出，整个代码仓库会显得非常乱。面对一大堆分支，谁也说不清到底哪个还活着，哪个已经没用了。所以，如果能够跟变更管理系统打通，自动化创建分支就最好了。
- 特性分支的原子性和完整性，保证一个特性的关联改动需要提交到一条分支上，而不是到处都是。同时，特性分支上的提交也需要尽量清晰，典型的就是原子性提交。
主干分支主干发布
团队只有一条分支，开发人员的代码改动都直接集成到这条主干分支上，同时，软件的发布也基于这条主干分支进行
前置条件：
为了保证主干分支的质量，自动化验收手段是必不可少的，因此，每一次代码提交都会触发完整的编译构建、单元测试、代码扫描、自动化测试等过程。
优势：
1.主干集成测试，代码冲突易于提前发现
2.主干代码安全稳定，每次测试通过后，都可以随时发布。
3.没有分支合并的冲突
劣势：
- 新功能代码在master主干上开发，若主干代码达不到稳定的标准，不可以进行项目发布
- master上主干开发有先后，有未完成的功能但又需要发布时，需要能隐藏未完成部分。
- 对质量门禁的要求高
总结
不同类型、规模和行业的软件项目所采用的分支策略可能各不相同，同时，发布频率、软件架构、基础设施能力以及团队的技术水平也会影响分支策略的实施效果。因此，很难存在一种适用于所有场景的通用分支策略。然而，有些分支策略的原则更适合快速迭代发布的需求，这也契合了 DevOps 的发展方向。基于此，我个人推荐主干开发结合特性分支的模式。这种方式的核心是团队共享一条开发主干，在此基础上为每个特性创建短期分支，完成开发与验收后迅速合并回主干。同时，在主干和特性分支上分别设置质量门槛和自动化验收流程。这样的策略能够提升代码集成效率，保持特性的独立性和主干的稳定性。
在实际操作中，需要遵循以下原则：
1. 团队应共享一个主干分支；
2. 特性分支的生命周期应尽量短，最好不要超过 3 天；
3. 每天至少向主干合并一次代码；如果特性分支存在超过 1 天，应每天同步主干代码；
4. 谨慎使用功能开关等技术手段，保持代码的简洁与历史记录的清晰；
5. 尽量减少并行分支，优先采用主干发布模式。
关于最后一点，是否需要发布分支取决于项目的发布模式。对于按版本发布的项目（如 App、智能硬件系统或需要大量外部联调的核心系统），可以根据固定的发布节奏创建发布分支。而对于发布频率较高、系统架构拆分后较为独立的应用，可以直接使用主干发布模式，并配合安全发布策略以确保整体发布质量。