本篇文章写于2021年03月28日，从公众号手工同步过来（博客搬家），本篇为原创文章。
关于Git分支管理，每个团队在不同阶段都有自己的管理策略，最近我们团队也争论过这个问题。
据了解，我们团队以前采用的是版本分支管理策略，也就是每次上线新版本都会创建一个新的版本分支，而新的需求开发也从当前最新的版本分支迁出一个新的需求分支开发，线上bug则在版本分支上修改然后发布。
在我接手项目的时候发现一个问题，由于拆分的微服务项目以及组件不在同一个project里面，我拉取全部项目代码后全部切换到master分支居然构建失败，提示xx类没有xxx方法，然后我全部切换到test分支情况依旧。后面同事找出的原因是新版本的代码没有合并到master分支。显然，版本分支成了项目的主分支，而master分支相当于一个弃用的分支。
由于项目目前全部容器化部署，并且走自动化部署，因此版本分支已经不适用了，目前采用的策略是线上master分支，测试test分支，当开发完成需求后将需求分支合并到test分支交给测试的同事去测试，测试完成后由开发合并到master分支部署。
这种策略同样存在问题，首先，开发不应该有权限修改master分支，其次，多个需求一同合并到master分支出现冲突会影响发布。
在发布新版本之前，我们应该确保已经解决所有代码冲突问题，因此应该多出一个分支，只有该分支的代码可以直接合并到master分支，所有需要在下个版本发布的需求分支通过测试后都应该先合并到该分支，在上线前再由项目负责人发起合并到master的请求，由部门主管处理合并请求，或者由项目负责人直接处理合并。
我并不看好自动触发构建发布生产环境这种策略（代码一合并到master分支就自动发布），因为往往在发版之前都需要做一些准备，等所有准备就绪后再按顺序去发版，例如数据库表结构的修改、配置文件的修改（开发人员不应该拿到生产环境的配置）。
此外，自动触发构建发布生产环境也不支持蓝绿/灰度发布，当然了，我们项目目前也不需要蓝绿/灰度发布，所以说，每个团队在不同阶段都有适合自己的管理策略。
以下分享笔者前后就职的三个公司当时采用的分支管理策略。
目前我们团队使用的分支管理策略
- 生产分支：
master - 测试分支：
test - 需求分支：
${需求}
开发人员开发需求需创建需求分支，需求开发完成后合并到test分支，测试人员在test分支上测试。
测试人员提交bug后，开发人员需切回需求分支修复bug，修复完成后合并到test分支，如此往复。
需求测试通过后，由开发合并到master分支发布。
线上bug直接在master分支修改，修改完成在master分支发布。
这种方案直接在master分支修复线上bug绕过了测试，而且每个开发都有master分支的提交权限，存在很大的风险，因此这种方案只适合小团队。
老东家使用的分支管理策略
- 开发分支：
dev - 生产分支：
master - 测试分支：
test - 需求分支：
${需求} - 版本分支：
relese-${version}
开发人员开发需求需创建需求分支，开发完成后由测试人员切换到该需求分支测试，或者批量测试的话就将多个需求分支合并到test分支。
测试人员提交bug后，开发人员需切回需求分支修复bug，修复完成后再通知测试人员切换到该分支测试，或是合并到test分支测试，循环往复。
需求测试通过后，由开发人员/开发组长将需求分支合并到dev分支，在约定的版本上线时间由开发组长提交将dev分支合并到master分支的请求，由主管合并分支。
最后，每次发版之后都将dev切出一个relese-${version}分支，线上bug在此分支修改，并且修改完成后测试需切到该分支测试，测试完成后就可以直接合并到master分支发布。
前前公司使用的分支管理策略
无分支管理策略，没有测试环境，需求在需求分支开发，开发完成后由开发自己测试，觉得没问题了就直接合并到dev分支，然后发布。master分支也是弃用的。有些简单的需求以及线上bug都是直接在dev分支改动。（没有测试就直接上线，非常的恐怖）。