需求

对于代码的管理，不知你是否遇到过以下几种情况：

• 存在多种版本管理工具，如svn、git，无法做到代码统一管理；
• 多人协作开发，代码合并冲突频发；
• 分支管理混乱，存在很多个性化分支；
• 提测代码被覆盖，严重影响开发进度；
• 代码仓库多用户管理及权限管理混乱；
• 等等

以上情况如果没有一个统一的代码仓库的管理规范，无论在测试阶段还是在生产上线过程中都将会是“一地鸡毛”。在此我们选择开源分布式版本控制系统Git作为代码仓库，并给大家介绍下已在企业生产实践中经过验证的Git分支管理规范。

环境介绍

代码版本在真正上生产环境前，需要经过一系列环境的测试验证：

1. 开发环境，研发人员本地开发环境用于调试开发；
2. 测试环境，研发人员进行系统联调测试；
3. 封测环境，测试人员进行初步整体验收测试；
4. 准生产环境，类生产环境，用于测试人员进行最终整体验收测试；

最终要上线的版本只有在经过测试人员的验收、评审后才可以交付到生产环境。

其中评审环节非常重要，需要测试、开发、运维对以下几方面做最终的确认：

• 确定Git分支是否合并到Master，保证生产使用Master分支的代码；
• 确定本次业务方需求涉及到的系统，以便有问题能够及时发现是否和本次变更有关；
• 确定上线系统是否在各测试环境验证通过，对于验收不通过的版本禁止发布；
• 确定上线系统发版顺序的前后依赖，避免因发布顺序导致的业务流转不通；
• 确定配置文件是否提交或更新到配置中心；
• 确定数据库相关DDL、DML是否需要DBA配合提前执行；
• 确定系统版本号、版本发布时间及系统相关研发人员；
• 等等其他细节；

经过评审后最终由运维按照版本发布时间进行上线，上线完成后由业务方进行验证。

Git分支管理

分支类型

为保证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流水线》内的文章。