如何管理Git分支
 据了解，我们团队以前采用的是版本分支管理策略，也就是每次上线新版本都会创建一个新的版本分支，而新的需求开发也从当前最新的版本分支迁出一个新的需求分支开发，线上bug则在版本分支上修改然后发布。 在我接手项目的时候发现一个问题，由于拆分的微服务项目以及组件不在同一个project里面，我拉取全部项目代码后全部切换到master分支居然构建失败，提示xx类没有xxx方法，然后我全部切换到test分支情况依旧。后面同事找出的原因是新版本的代码没有合并到master分支。显然，版本分支成了项目的主分支，而master分支相当于一个弃用的分支。 由于项目目前全部容器化部署，并且走自动化部署，因此版本分支已经不适用了，目前采用的策略是线上master分支，测试test分支，当开发完成需求后将需求分支合并到test分支交给测试的同事去测试，测试完成后由开发合并到master分支部署。 这种策略同样存在问题，首先，开发不应该有权限修改master分支，其次，多个需求一同合并到master分支出现冲突会影响发布。 在发布新版本之前，我们应该确保已经解决所有代码冲突问题，因此应该多出一个分支，只有该分支的代码可以直接合并到master分支，所有需要在下个版本发布的需求分支通过测试后都应该先合并到该分支，在上线前再由项目负责人发起合并到master的请求，由部门主管处理合并请求，或者由项目负责人直接处理合并。 我并不看好自动触发构建发布生产环境这种策略(代码一合并到master分支就自动发布)，因为往往在发版之前都需要做一些准备，等所有准备就绪后再按顺序去发版，例如数据库表结构的修改、配置文件的修改(开发人员不应该拿到生产环境的配置)。 此外，自动触发构建发布生产环境也不支持蓝绿/灰度发布，当然了，我们项目目前也不需要蓝绿/灰度发布，所以说，每个团队在不同阶段都有适合自己的管理策略。 以下分享笔者前后就职的三个公司当时采用的分支管理策略。 据了解，我们团队以前采用的是版本分支管理策略，也就是每次上线新版本都会创建一个新的版本分支，而新的需求开发也从当前最新的版本分支迁出一个新的需求分支开发，线上bug则在版本分支上修改然后发布。 在我接手项目的时候发现一个问题，由于拆分的微服务项目以及组件不在同一个project里面，我拉取全部项目代码后全部切换到master分支居然构建失败，提示xx类没有xxx方法，然后我全部切换到test分支情况依旧。后面同事找出的原因是新版本的代码没有合并到master分支。显然，版本分支成了项目的主分支，而master分支相当于一个弃用的分支。 由于项目目前全部容器化部署，并且走自动化部署，因此版本分支已经不适用了，目前采用的策略是线上master分支，测试test分支，当开发完成需求后将需求分支合并到test分支交给测试的同事去测试，测试完成后由开发合并到master分支部署。 这种策略同样存在问题，首先，开发不应该有权限修改master分支，其次，多个需求一同合并到master分支出现冲突会影响发布。 在发布新版本之前，我们应该确保已经解决所有代码冲突问题，因此应该多出一个分支，只有该分支的代码可以直接合并到master分支，所有需要在下个版本发布的需求分支通过测试后都应该先合并到该分支，在上线前再由项目负责人发起合并到master的请求，由部门主管处理合并请求，或者由项目负责人直接处理合并。 我并不看好自动触发构建发布生产环境这种策略(代码一合并到master分支就自动发布)，因为往往在发版之前都需要做一些准备，等所有准备就绪后再按顺序去发版，例如数据库表结构的修改、配置文件的修改(开发人员不应该拿到生产环境的配置)。 此外，自动触发构建发布生产环境也不支持蓝绿/灰度发布，当然了，我们项目目前也不需要蓝绿/灰度发布，所以说，每个团队在不同阶段都有适合自己的管理策略。 以下分享笔者前后就职的三个公司当时采用的分支管理策略。 （编辑：潍坊站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
