背景

git代码分支管理是devops的一个重要组成部分。而现状是，各个业务线没有统一的代码分支管理规范，这样会降低研发效率和增加线上代码的风险。所以需要一个统一的代码管理以及配套的产物环境管理。

方案原则：

尽量减少分支数量，降低分支管理成本，减少代码分支操作的失误。
要满足日常开发的易操作性和灵活度。
充分利用CICD的自动化管理代码分支功能，提升代码管理的效率，减少手动处理的出错率。
项目之间的开发和部署类型有比较大的差异，需要区别对待。

分支定义

分支	解释	分支名称
开发分支	开发分支。一个需求对应1个或多个 feature，每一个 feature 会对应一个分支。	dev_{base_version}_{feature1}base_version：从哪个 master 版本创建的。feature: 能够识别功能内容的简短说明。
开发联调分支	开发联调分支。只要涉及开发联调的 feature 分支都可以合并到这个分支。支持一个或多个	1. 如果一个开发联调环境就可以满足开发需求，那么就只需要一个分支，分支名称为：dev2. 如果需求多个开发联调环境，分支就需要多个：dev_{XXX}{XXX}:自定义来识别具体的开发联调分支。
版本分支	test_{online_version}每次版本升级时，会对应一个版本分支如 dev_2.0 分支只能由属于 2.0 版本的 feature 分支合并进来。用于测试人员进行版本功能的测试。如果有多个版本并行开发和测试的场景。这里支持多个版本分支来支撑多个版本并行测试。	test_{online_version}online_version：产品版本号。
发布分支	主分支，不能直接commit,仅通过版本分支向 master分支 merge 修改代码。	master

环境定义

运行环境	定义	对应分支
dev（开发联调环境）	给开发人员提供的开发联调环境, 支持一个或多个环境。	开发联调分支
test(测试环境)	给测试人员测试环境,支持一个或多个环境。	test_{online_version}
准生产环境（包括UAT,stage等环境）	接近生产的环境，正式上线前最后一次测试。	master 分支
poduce(生产环境)	生产环境的环境	master 分支

版本号规范：

产品版本，技术版本。关联关系。

分支与环境管理流程

根据公司日常开发和部署环境的不同，主要分为公有云，国际化，私有化。

公有云分支管理主流程

第一步, 首先对基于 master 分支创建开发联调分支（dev或dev_{XXX}），开发联调分支需要尽量保证版本不落后与 master 分支。

第二步, 确认3.0版本需求后，从 master 2.0 拉出 version_3.0 分支, 这个分支用于3.0版本的测试。

第三步，从version_3.0 分支拉出两个 feature 分支，分别为 feature_2.0_01 和 feature_2.0_02。

第四步，当代码编写完成后，feature_2.0_01 分支和 feature_2.0_02 分支分别合并到开发联调分支, 在开发联调环境进行开发环境的联调。

第五步，开发联调结束后，feature_2.0_01 分支和 feature_2.0_02 分支分别合并到 version_3.0 分支.

第六步，并把version_3.0 分支部署在 test 环境，测试人员进行测试。

第七步，测试通过后，把 version_3.0 分支合并到 master 分支。

第八步，把 master 分支代码部署在准生产环境。

第九步，准生产环境测试没有问题，就把 master 分支部署在生产环境。如果准生产环境有问题重新通过 feature 分支再按上述步骤再走一遍。

如果在发布过程中有别的版本分支合并到 master 分支，会造成代码冲突，这种情况怎么解决呢？

方法是：如果一个版本分支在发布阶段，禁止其它版本分支合并master分支。

公有云线上 bug 分支管理流程

线上的bug 分为非常紧急的 hotfix 和不是很紧急常规线上 bug。

Hotfix 场景的分支管理流程

对于 hotfix 的场景，需要从 master 分支拉一个当前生产环境的代码。命名规范是按日期和时间命名的，如 hotfix_2023-01-02-13, 代表2023年1月2号13点拉的分支。
在这个分支上提交代码，然后合并到 master 然后把 master 分支代码发布到生产环境。
生产环境验证没问题就在 master 分支打一个 1.1 的 tag。
如果这时候有正常的版本迭代行为，那么就在版本分支需要及时把 master 分支合并到版本分支上。

常规线上 bug 的分支管理流程

对于这种情况，就直接把这个fix bug 的需求作为下一个版本迭代里的一个feature 就可以了。后面的流程和主流程都是一样的了。

多版本并行开发的管理流程

总结

按照项目开发的流程，给大家再梳理一下分支名，环境以及对应的研发行为。

阶段	涉及的分支名	环境	研发行为
开发	dev_{base_version}_{featrure01}	没有	1. 研发经理从 master 拉取版本测试分支。

开发人员从版本测试分支拉取自己的 feature 分支。
开发人员在 feature 分支上开发。 | | 联调 | 联调分支：1. dev_common2. dev_common_{XXX} | 开发联调环境 | 1. 如果联调分支落后于 master 分支就把 master 分支合并到联调分支。
合并后的联调分支重新编译部署在开发联调环境中。
开发人员把某个 feature 分支合并到联调分支。
开发人员在开发联调环境验证代码功能。 | | 提测 | dev_{online_version} | test 测试环境 | 1. 研发经理把 feature 分支到版本测试分支。
研发经理把版本测试分支发布到 test 环境
测试人员在 test 环境进行测试。 | | 准上线 | master | 准生产环境 | 1. 研发经理把提测分支 dev_{online_version}合并到 master 分支。
研发经理把合并后的 master 分支打上 tag。
研发经理把 master 分支代码的tag版本发布到准生产环境。
测试人员测试准生产环境。 | | 上线后 | master | produce 生产环境 | 1. 研发经理把 master 分支代码发到 produce 生产环境。 |

私有化分支管理主流程

基于公有云的master分支，创建国际化和私有化的 master 分支。

当私有化项目代码有升级的需求时，这时需要把 master 分支合并到私有化分支或国际化分支。

私有化项目和国际项目得到相应的 master 分支后其它的分支，环境，流程和公有云一样。

为每一个需要私有化的客户创建一个私有分支，这个私有分支就相当于私有化的master。其它的逻辑和公有云分支管理是一样的。命名规则为 master_客户。如 mater_beiyin（代表北银的私有化 master 分支）。
为国际化项目创建一个 master_international 的分支。

该如何管理开发过程中的Git代码分支

背景