文章目录
- [1. 背景](#1. 背景)
- [2. 分支管理实践](#2. 分支管理实践)
-
- [2.1. 敏捷开发中分支管理面临的问题](#2.1. 敏捷开发中分支管理面临的问题)
- [2.2. 分支管理策略](#2.2. 分支管理策略)
- [2.3. 还需要注意的一些问题](#2.3. 还需要注意的一些问题)
- 3.总结
1. 背景
在实际的开发工作中，我们往往会面临多任务并行研发，多个环境管理的情况，这种情况下，一个合适的分支管理策略就显得尤为重要。特别是在使用敏捷开发流程、DevOps 的团队中，由于快速响应、需求的灵活性等特征，分支管理的必要性则更加突出。
我在网上查看过一些分支管理策略的方法论，例如：git flow , github flow , one flow , gitlab flow 等，但是在管理敏捷开发 时，依然是差强人意。在这篇文章中，会分享一个我们公司的实践，它是由gitlab flow拓展出来的分支管理策略。
2. 分支管理实践
2.1. 敏捷开发中分支管理面临的问题
敏捷开发流程在研发中最大的特点就是需求灵活多变 和小步快跑的迭代式开发，这就给的分支的管理带来了一定的挑战，试想一下如下的一些场景：
- 在研发的过程中，遇到线上问题需要立即处理并上线。
- 在同一个项目的需求A研发完成正在debug的过程中，突然插入了紧急的需求B，且要求需求B要先于需求A上线。
- 有两个需求需要并行研发，优先级都一样，谁先做完谁先上线。
- 多人研发时，每次合并的冲突特别多。
这其中的一些问题，在现有的git管理策略中并不太容易处理，为此，我们修改了分支管理策略和规范，以适应这种变化。
2.2. 分支管理策略
在说分支管理策略之前，我先说一下我们的几个环境。我们一共有三个环境 ，分别是：测试环境、预发环境、生产环境。
- 测试环境：用于提测后的第一轮集成测试，这一轮测试的bug会相对较多，我们会在这个环境中修复研发过程中出现的所有bug。
- 预发环境 ：预发环境和生产环境连接同样的存储中间件，例如MySQL和Redis，在数据上是共享的，只是在其他中间件上做了隔离。这个环境的目的是在于验证测试环境和生产环境 由于环境的差异带来的问题，一般来说，预发环境修复问题后，生产基本上就没有更多的问题了。
- 生产环境：就是项目正式上线的环境。
针对这三个环境，我们了几种不同的分支类型 ，长期分支为：master ，develop，短期分支为：release-版本号，feature , hotfix 三个，我分别解释一下作用。
- master ：保存生产环境最新版本的代码，保证的是从master拉出来的代码一定是可以直接上线的。
- develop ：开发和测试分支，发布测试环境的时候使用的分支，研发可以根据需要选择是否在develop上研发新版本。
- release-版本号 ：预发分支，一般用于预发验证和生产发布，这个分支保留两到三个版本迭代。
- feature ：功能迭代分支，一般是在有并行研发的情况下拉取的分支，保证需求之间的隔离，这个分支在上线后删除。
- hotfix ：问题处理分支，线上紧急问题拉取这个分支进行修改。
下面通过一个时间序列图来表示一个相对复杂的研发场景：
图中标明了序号和每一步做了什么，这里简要的描述一下关键点：
- 所有的研发分支（功能分支，hotfix分支），都是从
master拉取的，这样保证研发分支的代码都是在线上环境的版本中拓展出来的，目的是每一个研发分支都能够独立的上线。 - 功能分支研发完成提测后，都合并到
develop发布测试环境，这个阶段主要是解决业务流程、细节、边界问题等造成的bug。 - 预发分支的拉取，图中是按功能分支拉取的 ，这是因为一般一次发布规划的就是一次迭代中的这批功能，当然，如果在项目管理的过程中发现两个功能分支的完成时间非常相近，也可以合并到同一个预发分支进行验证和发布。
- 发布完成后，需要将最新的代码合并到master并打好版本tag备案 ，同时将master合并 到
develop和没有上线的功能分支中，避免后续代码越写越多后带来的bug。 hotfix一般是给线上的代码打补丁，不会有特别大的改动（如果有，规划到下一次迭代中是更好的方式），所以在修改完成之后，通过预发分支进行验证就好了，非必要不用在测试环境再走一遍测试。
2.3. 还需要注意的一些问题
以上的策略实现了灵活管理多需求独立上线，降低了产生冲突的概率，能够较好的适配敏捷开发的节奏。在实际工作中，配合项目管理流程达到的效果会更佳，例如：
- 在做任务拆分和迭代规划时，将关联性强的需求分配到同一个功能分支中一同上线，这样可以很大程度上避免不同分支修改同一行代码，减少冲突的概率。
- 在研发流程中，做上线规划时，将上线完成后合并到master 这一步规划到上线文档中，避免因遗忘导致后续迭代拉取的不是最新的代码。
- 如果是在一个互相信任 的团队，并且团队成员的平均水平较高，可以使用上述的方式，每个人都可以进行合并发布。但如果不是这样的团队，为了减少发布的风险，需要调整流程，合并到master时需要做合并审查，并且只有管理人员可以通过master分支进行发布。
除了管理上的问题之外，有条件的话建立CICD流水线，并且通过容器的方式对发布流程进行管理，会最大化的发挥这个分支管理策略的作用。
3.总结
本篇讲的是一个适用于敏捷开发的分支管理策略，再一个互相信任且水平相对较高的团队中，可以将这个策略发挥到极致，完全匹配敏捷开发中需求灵活多变。
这个策略经过我司多年的实践，足以应对大部分的研发迭代场景，希望对大家能够有所帮助，如果对这个流程有任何疑问及建议，欢迎留言讨论！