标签：content class 命名 resolve pull source 开发 front 关闭
我们采用目前的保留的分支体系： 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 |
|
|
√ |
三、版本发布
|
|
研发 |
测试 |
审查 |
|
创建并推送发布分支 |
√ |
|
|
|
创建 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 → 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再次测试，上线。
参考文档：https://blog.csdn.net/BoReFrontEnd/article/details/97391441
标签：content class 命名 resolve pull source 开发 front 关闭
原文地址：https://www.cnblogs.com/dongv5/p/12419276.html
