关于Git分支管理，各个团队在不同阶段都有自己的管理策略，最近我们团队也争论过这个问题。据了解，我们团队之前采用的是版本分支管理策略，即每推出一个新版本，都会创建一个新的版本分支，同时新需求的开发也会从当前最新版本分支转移到开发的新需求分支。在线bug在version分支上修改发布。当我接手这个项目时，我发现了一个问题。由于拆分出来的微服务项目和组件不在同一个项目中，所以我拉取了所有的项目代码，切换到了master分支。构建失败，提示xx类没有xxx方法，然后我全部切换到test分支还是一样。后来同事发现的原因是新版本的代码没有合并到master分支。很明显，version分支成为了项目的主分支，而master分支相当于一个deprecated分支。由于项目目前全部容器化，自动部署，版本分支不再适用。目前的策略是使用线上master分支，测试test分支。开发完成后，需求分支会合并到测试分支，交给测试分支。同事来测试，测试完成后，将开发合并到master分支进行部署。这种策略也存在问题。首先，开发者不应该有修改master分支的权限。第二，合并到master分支的多个需求之间的冲突会影响发布。在发布新版本之前，我们应该确保所有的代码冲突都已经解决，所以应该多一个分支，只有这个分支的代码才能直接合并到master分支中。所有需要在下一个版本中发布的需求分支都应该先通过测试。合并到这个分支，然后项目负责人在上线前发起合并到master的请求，部门负责人处理合并请求，或者项目负责人直接处理合并。我不看好生产环境自动触发构建发布的策略（代码一合并到master分支就自动发布），因为发布前往往需要做一些准备工作，并且然后在一切准备就绪后按顺序发布，例如修改数据库表结构，修改配置文件（开发者不要拿到生产环境的配置）。另外，自动触发构建发布的生产环境不支持蓝绿/灰度发布。当然，我们的项目目前不需要蓝绿/灰度发布。因此，每个团队在不同阶段都有自己的管理策略。下面分享一下笔者前后工作过的3家公司的网点管理策略。我们团队目前使用的分支管理策略生产分支：master测试分支：test需求分支：${requirement}开发人员需要创建一个需求分支来开发需求，需求开发完成后合并到测试分支，以及测试人员在测试分支上进行测试。测试人员提交bug后，开发人员需要切换回requirement分支修复bug，修复完成后合并到test分支，以此类推。需求测试通过后，由development合并到master分支发布。线上bug直接在master分支上修改，修改完成后在master分支上发布。这种方案直接绕过master分支上的测试上线修复bug，而且每次开发都有master分支的提交权限，风险很大，所以这种方案只适合小团队。老东家使用的分支管理策略开发分支：dev生产分支：master测试分支：test需求分支：${requirement}版本分支：relese-${version}开发人员需要创建需求分支来开发需求，测试人员开发完成后会负责切换到需求分支进行测试，或者将多个需求分支合并到测试分支进行批量测试。测试人员提交bug后，开发人员需要切换回需求分支修复bug。fix完成后，通知测试人员切换到分支进行测试，或者合并到测试分支进行测试，如此循环往复。需求测试通过后，开发人员/开发组长将requirements分支合并到dev分支，开发组长在约定的版本上线时间提交将dev分支合并到master分支的请求，主管将合并分支。最后每次版本发布后，dev都会切出一个release-${version}分支。在线bug在本分支修改，修改完成后需要切到本分支进行测试。测试完成后，可以直接合并到master分支发布。之前公司使用的分支管理策略，没有分支管理策略，也没有测试环境。需求在需求分支中开发。开发完成后，开发会自行测试。如果没问题，直接合并到dev分支发布。主分支也被弃用。一些简单的需求和线上bug，直接在dev分支改。（不测试就上线很可怕）。本文转载自微信公众号“爪哇艺术”，可通过以下二维码关注。转载本文请联系爪哇艺术公众号。
