【Git管理篇】GitLab 版本分支管理策略（二）

我们采用目前的保留的分支体系： master 、 develop（将feature、hotfix合到develop）、release

一、代码分支

分支	说明	创建来源分支	代码来源	目标分支	代码输入方式	生命周期	命名规则★
★master	主干分支，通常作为代码基线，所有发布的代码最终都会合并到此分支。	无	release、hotfix	develop	Pull request	长期	Master
★develop	开发分支，通常作为其他分支的源分支，也最终会合并回此分支	无	feature、 release、hotfix	develop	Pull request	长期	Develop
feature	功能分支，用于为未来的应用版本开发新的功能需求	develop	developer	develop	Merge	并入目标分支后，删除	Feature/{jira_issue_key}
★release	发布分支，用于辅助新版本发布的准备工作，例如小bug的修复，或者版本号的修改等等	develop	developer、 hotfix	Develop、master	Merge	并入目标分支后，删除	Release/{jira_issue_key}
hotfix	修复分支，用于正式版本的紧急修复	master	开发者	Develop、master、release	Merge	并入目标分支后，删除	Hotfix/{jira_issue_key}

二、功能开发

	研发	测试	审查
创建并推送功能分支	√
创建 feature → develop 的 pull request	√
代码审查			√
功能测试		√
合并代码到开发分支			√
关闭pull request			√

三、版本发布

【Git管理篇】GitLab 版本分支管理策略（二）

	研发	测试	审查
创建并推送发布分支	√
创建 realease → develop 的 pull request	√
创建 realease → master的 pull request	√
审查 realease → develop 的 pull request			√
审查 realease → master 的 pull request			√
发布测试		√
合并代码到开发分支			√
合并代码到主干分支			√
关闭realease → develop 的 pull request			√
关闭realease → master 的 pull request			√
创建代码标签		√

四、Hotfix修复

【Git管理篇】GitLab 版本分支管理策略（二）

	研发	测试	审查
创建并推送修复分支	√
创建 hotfix → develop 的 pull request	√
创建 hotfix → release 的 pull request	√
创建 hotfix → master的 pull request	√
审查 hotfix → develop 的 pull request			√
审查 hotfix → release 的 pull request			√
审查 hotfix → master 的 pull request			√
发布测试		√
合并代码到开发分支			√
合并代码到发布分支			√
合并代码到主干分支			√
关闭hotfix → develop 的 pull request			√
关闭hotfix → release 的 pull request			√
关闭hotfix → master 的 pull request			√
创建代码标签		√

五、场景模拟

Master分支：一定是最后一次 commit已经上线，或者他已经顺利通过了 QA、PD、PO 的打磨锻造，分分钟拔出来上线。（ps：不用怕会祭天）

（1）常规开发

新建code库，库中 master和所有其他分支，只有项目负责人有写入权限

从code库中master克隆一个分支出来，命名为：branch_1.0.0 【develop】

开发人员在此分支上修改，开发和自测完后，向 code库发起pull request，请求代码审查和合并

pro-master 进行代码审查、合并后，提交测试。头缺陷，继续在 branch_1.0.0 修复，然后发起pull request，如此循环，知道最后，测试完成，可以将 branch_1.0.0 上线

上线后，将此branch_1.0.0分支合并到msster，并给branch_1.0.0打上tag。【ps：理论上，此时的 master和branch_1.0.0是完全一致的】

（2）并行开发

假定：branch_1.0.1 和 branch_1.0.2 同时并行开发

情况：

第一种： branch_1.0.1 先开发完，测试完，上线完之后，branch_1.0.2 才准备提测。此时，需要在合并测试版本branch_1.0.2时，将master内容一起合并，合并之后再进行测试

第二种： branch_1.0.1 和 branch_1.0.2 同时开发完，可以合并成一个release版本，或者合并成到 branch_1.0.2 进行测试

第三种： branch_1.0.1 开发完，测试完，未上线，branch_1.0.2 开发完，准备提测，此时操作和第二种一样

第四种： branch_1.0.1 和 branch_1.0.2 都开发完，需要同时测试（不建议），只能一个分支先测试完上线，另一个分支需要合并上线后的master再次测试，上线。

相关推荐