多人协作如何管理Git分支

Java艺术 2021-09-07

417

关于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
分支改动。（没有测试就直接上线，非常的恐怖）。

收集更多

欢迎大家留言分享你们团队目前使用的分支管理策略以及存在的问题。

数据库

文章转载自Java艺术，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

多人协作如何管理Git分支

目前我们团队使用的分支管理策略

老东家使用的分支管理策略

前前公司使用的分支管理策略

收集更多

评论

相关阅读