当前位置：首页 > news >正文

【git实践】分享一个适用于敏捷开发的分支管理策略

news 来源：原创 2025/7/18 23:03:59

文章目录

1. 背景
2. 分支管理实践
- 2.1. 敏捷开发中分支管理面临的问题
- 2.2. 分支管理策略
- 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.总结

本篇讲的是一个适用于敏捷开发的分支管理策略，再一个互相信任且水平相对较高的团队中，可以将这个策略发挥到极致，完全匹配敏捷开发中需求灵活多变。
这个策略经过我司多年的实践，足以应对大部分的研发迭代场景，希望对大家能够有所帮助，如果对这个流程有任何疑问及建议，欢迎留言讨论！