需求
对于代码的管理，不知你是否遇到过以下几种情况：
-
存在多种版本管理工具，如svn、git，无法做到代码统一管理;
-
多人协作开发，代码合并冲突频发;
-
分支管理混乱，存在很多个性化分支;
-
提测代码被覆盖，严重影响开发进度;
-
代码仓库多用户管理及权限管理混乱;
-
等等
以上情况如果没有一个统一的代码仓库的管理规范，无论在测试阶段还是在生产上线过程中都将会是“一地鸡毛”。在此我们选择开源分布式版本控制系统Git作为代码仓库，并给大家介绍下已在企业生产实践中经过验证的Git分支管理规范。
环境介绍
代码版本在真正上生产环境前，需要经过一系列环境的测试验证：
1、开发环境，研发人员本地开发环境用于调试开发;
2、测试环境，研发人员进行系统联调测试;
3、封测环境，测试人员进行初步整体验收测试;
4、准生产环境，类生产环境，用于测试人员进行最终整体验收测试;
最终要上线的版本只有在经过测试人员的验收、评审后才可以交付到生产环境。
其中评审环节非常重要，需要测试、开发、运维对以下几方面做最终的确认：
-
确定Git分支是否合并到Master，保证生产使用Master分支的代码;
-
确定本次业务方需求涉及到的系统，以便有问题能够及时发现是否和本次变更有关;
-
确定上线系统是否在各测试环境验证通过，对于验收不通过的版本禁止发布;
-
确定上线系统发版顺序的前后依赖，避免因发布顺序导致的业务流转不通;
-
确定配置文件是否提交或更新到配置中心;
-
确定数据库相关DDL、DML是否需要DBA配合提前执行;
-
确定系统版本号、版本发布时间及系统相关研发人员;
-
等等其他细节;
经过评审后最终由运维按照版本发布时间进行上线，上线完成后由业务方进行验证。
分支类型
为保证Git分支的有序使用，结合各环境的规划我们定义了以下分支：
1、Master分支
主分支，用于准生产环境发布，与生产环境保持一致;
2、Hotfix分支
补丁分支，用于生产环境上的版本进行Bug修复;
3、Release分支
发布分支，用于封测环境的整体验收测试;
4、Feature分支
功能分支，用于测试环境的功能联调测试;
其中，本地仓库并不是Git分支，而是基于远程Feature分支拉取到本地的开发仓库，用于开发环境的开发调试。
分支使用场景
1、功能开发
当有新功能开发时，需要从Master分支clone到Feature分支;
开发人员基于远程Feature分支拉取到本地的开发仓库，进行本地开发调试;
当Bug分支有补丁修复时，需要首先将其合并到远程Feature分支，然后再合并到本地Feature仓库;
2、Bug修复
当线上版本有Bug时，需要基于Master分支clone到Hotfix分支;
开发完成后需要将其合并到Master分支，并在准生产环境进行验收并发布;
验收发布后需要将代码合并到Feature分支，然后再合并到本地Feature仓库，完成闭环;
3、测试环境发布
将本地仓库的代码合并至远程Feature分支;
打包发布，开发人员联调测试;
4、封测环境发布
将Feature分支合并至Release分支;
打包发布，测试人员初步整体功能联调测试;
5、准生产环境发布
将Release分支合并至Master分支;
打包发布，测试人员最终整体功能验收测试;
6、标签管理
Master代码验收通过，需要基于“版本号+日期”打标签并代表本次变更完成;
7、Master分支锁定
Master分支只有在发版窗口前才可以提交合并，其他时间锁定，避免Master分支混乱;
以上场景需要注意的是，需要适时同步下远程分支的代码，否则很容易导致代码冲突。
多分支流水线
为保证各环境的系统版本的快速的CI/CD，我们一般会针对系统应用、环境、分支创建多个work，这无疑也会加大配置管理的难度。
因此我们可以使用Jenkins 扩展共享库和多分支流水线的功能，实现一个work对应多个环境、多个分支的需求，这无疑减少了一定的工作量，有兴趣的可以参考公众号内实践应用《CI/CD流水线》内的文章。
