1.背景
目前笔者所在公司的开发团队基本都采用Git来做代码版本控制，为了更有效地协同开发人员之间，以及开发、测试、上线各环节的工作，公司也出具了对应的git分支管理方面的规范。规范主要目的是提高开发协同效率，针对不同场景git管理策略肯定会所有不同。最好的不一定是最合适的，在具体实践过程中不同团队会结合其内部实际情况，在基本满足公司git管理规范的前提下做适当的调整，形成一套最合适其团队的版本管理规范。本文主要介绍笔者所在开发团队在实践过程中形成的分支管理约定、日常分支操作流程等内容，希望对大家有所帮助。
2.分支管理
| 序号 | 分支名称 | 分支用途 | 分支说明 |
|---|---|---|---|
| 1 | master | 生产环境的稳定分支 | 始终与生产环境运行代码保持一致，除了从release分支或生产环境Bug修复hotfix分支进行merge，不接受任何其它修改。（应受保护，不允许提交只能合并）约定：在master分支上合并提交都必须有Tag ， Tag标签用于标识每次生产发布操作；针对tag便签管理建议遵循以下原则：1、命名规则： tag-版本信息 （一般跟着每次生产发布的分支定义的版本来，例如本次发布为release-1.2.0分支代码，则本次tag命名为tag-1.2.0，如果发布的是生产环境修复分支，则在本次发布的版本号第三位加1，如tag-1.2.1）2、时间节点：release分支或者修复分支发布生产环境后合并回master分支时打tag便签3.、内容格式：发布内容 1.1 ******* 1.2 *******发布版本release-1.2.0发布时间：2020.04.15 生产环境的发布时间 |
| 2 | release-主版本.次版本.0 | release分支 | 测试通过后待上线的分支，都是测试验证通过后从develop分支拉取创建,用于预生产环境、生产环境发布约定：1、命名规则：release-主版本.次版本.02、release分支依赖外部版本必须为稳定版本，正常来说在测试分支（develop）时候就应保证依赖为稳定版本，即保证我们上线的版本与测试版本完成一致。但目前我们很多时候依赖的中心是同时发布的，往往是在release版本后才能修改本次发版引用的外部版本为稳定版本（如果只是依赖dto，最好约定保证dto不要加入多余的依赖，那问题不大；但对于依赖类似基础框架的，强烈建议上测试用的是确定的稳定版本），这在一定程度上存在风险。3、每次上线时，先将release分支在测试环境部署验证通过后获取镜像，直接拿本次的镜像去预生产\生产环境部署4、时间节点：每次上线生产环境打tag后，可以定期清理线上release分支 |
| 3 | develop | 提测分支 | 该分支主要作为集成测试分支，所有的测试环境部署该分支进行测试，现在接入pdca管理后，提测时直接选择应用的develop。每次开发提测或者修复测试反馈的缺陷都应提交相应的PR（合并请求），由指定人员审核合并。正常来说在进入测试阶段不要频繁往该分支提交代码部署，除非出现阻塞性bug，一般是由测试人员验证完后进行统一缺陷验证时候再合并部署对应develop分支，否则有可能会影响测试验证。每次功能全部验证完成后，不要再向该分支提交任何优化代码，除非经过测试同意合并后由测试进行再次验证。（应受保护，不允许提交只能由指定人员合并） |
| 4 | feature-版本号 | 功能分支 | 该分支主要用于功能开发，该分支每次都从develop分支拉取创建，开发完成完提测合并到develop分支，一般每个月的一个版本对应一个feature分支。约定：1、命名规则：feature-提测版本号（例如2020年0730版本，则命名为feature-200730)2、时间节点：每个月新拉feature分支后，可以清理上个月的feature分支 |
| 5 | hotfix-修复版本号 | 紧急版本分支 | 当生产环境上面有bug时，从master分支拉取创建hotfix分支。当bug修复后准备发布时，将代码合到master分支进行分布,并同时将该分支合并到Develop约定：1、命名规则：hotfix-主版本.次版本.1（在末尾版本号依次加1）2、时间节点：发布完一段时间后没问题就删除此分支3、(星星)注意：这里的生产环境可能并非是严格意义上的生产环境（例如前期我们是将预生产给用户实际使用，这里预生产就相当于我们现在所说的生产环境）。现在我们使用的预生产其实只是在正式投产前的一个产品验证，在这个环境发布修复版本，不需要创建hoxfix分支，可在直接在release分支修改后验证通过发布，将代码再合并回develop分支 |
| 6 | feature-union-标识 | 开发联调集成分支（非必需） | 该分支主要解决多个开发并行版本共用一个开发环境进行联调的问题，也是从develop分支拉取创建约定：1、命名规则：暂时我们的版本都是以月为版本，可以用feature-union-年份月份命名(例如feature-union-2007），后续命名年份月份可以更换为其他标识2、时间节点：每次集成的所有版本发布后，即可删除该分支。 |
3.流程规范
3.1 规范依据
以GitFlow工作流模式作为协作流程规范。Gitflow为不同的分支分配一个很明确的角色，并定义分支之间如何和什么时候进行交互。 除了使用功能分支外在做Bug修复、维护和预发布时也使用各自的分支。同时通过Pull Requests、隔离性开发实现更高效的协作。以下是gitflow的常见的工作流程图：
3.2 规范实践
版权声明：本文为m0_37774696原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接和本声明。