常用的git分支管理方法都在这了

https://blog.csdn.net/qq_37974755/article/details/126304583

转载：https://zhuanlan.zhihu.com/p/150179524?utm_id=0

 

分支概述

• 分支流程中包含4类分支，分别是master、release、dev、hotfix，各类分支作用和生命周期各不相同。
• master：该分支是线上稳定版本代码，禁止提交代码
• dev：从master分支切出，是需要开发代码的分支，所有开发均在dev分支
• release：从dev分支切出，dev合并到release分支进行测试，同时也是发布分支
• hotfix：从master分支切出，解决线上紧急BUG的修复

角色及职责

• 开发组员
• dev、hotfix的分支开发

 

• 开发组长
• 从master打dev、release、hotfix分支
• dev、hotfix的分支开发
• 从dev分支合并到release
• 从release分支合并到master
• 将master合并到release分支
• 删除hotfix分支

分支记录存放位置 - Git->wikis->分支记录

版本号规范

• dev及release版本号命名规则 - <主版本号>.<副版本号>.<发布号>
• 主版本号设置规则
• 产品的主体构件进行重大修改，主版本号加1
• 产品的主体构件之间的接口协议重大修改，主版本号加1

 

• 副版本号设置规则
• 主版本号变更时，副版本号置0
• 数据结构变更(新增或修改注释含义的情况除外)，副版本号加1
• 若副版本号累加至超过90时，采用主版本号进位制，主版本号加1，副版本号重新置0

• 发布号设置规则
• 主版本号或副版本号变更时，发布号置0
• 若发布的版本无数据结构变更，则发布号加1

 

• hotfix版本号命名规则 - <主版本号>.<副版本号>.<发布号>
• hotfix由于即修即删，因此同release版本的版本号即可

主版本号和副版本号的变更标志着重要的功能或结构变动。发布号的变更，用于体现小的功能变更

各种场景流程规则

正常开发常规版本

• 当需要开发常规迭代时：

分值类型命名规范创建自合并到备注devdevx.x.xmasterrelease新功能开发完成后提测releaseggreleasex.x.xdevmaster新版本发布后

• 从master分支创建dev分支，例如：dev1.3.0
• 在dev分支上开发代码，push到远程仓库
• dev分支代码开发完毕，合并到release分支，例如：release1.3.0 <开发组长>
• 测试人员在release1.3.0分支进行测试，测试完毕后拿release1.3.0分支部署
• 上线验收完毕后将release1.3.0分支合并到master分支

紧急&BUG修复版本流程规则

• 当需要修复线上紧急BUG时：

分值类型命名规范创建自合并到备注hotfixhotfixmasterreleaseBUG修复后提测

• 从master分支创建hotfix分支
• 在hotfix分支修复BUG，push到远程仓库
• BUG修复完毕后切出最新的release分支，例如：release1.3.1 <开发组长>
• 测试人员在release1.3.1分支进行测试，测试完毕后拿release1.3.1分支部署
• 上线验收完毕后将release1.3.1分支合并到master分支

注意事项

• dev分支之间不能合并代码
• release分支不能合并到dev分支
• 从dev分支合并到release分支测试时，只能合并dev分支上自己的commit到release，可参考git cherry-pick、git rebase命令
• 如发现当前release分支测试时，落后于master一个版本及以上，需要将master合并至当前release分支；