分支模型
集中式的分支模型
目前团队使用的模式属于老旧的集中式分支模型，简单的总结就是：
- 开发时： 团队的所有成员都在dev分支上开发（也支持少部分的特性分支feature-xxx）。
- 测试时： 当功能需要上测试环境测试时，把dev合并到test分支，使用test分支在测试环境中测试。
- 灰度时： 在发布到生产环境之前，需要经过灰度发布，此时需要把测试通过后的dev分支合并到master，灰度环境使用master分支进行灰度测试。
- 生产时： 最后在灰度环境也确保没问题后，直接把master发布到生产环境。
优点
- 操作容易
- 简单高效
弊端也显然易见
-
迭代计划内的功能临时说这版本不发或者计划内完成不了
当一个功能已经在开发当中，没有使用feature分支来开发，已经进入dev分支，然而可能由于预估时间太短，或者是逻辑没想清楚，在迭代期内无法完成，或者临时说此功能不要上，这时候还要把dev的代码清理掉，从某种意义上说dev已经被不必要的代码污染了，会增加风险。
-
灰度发布过程中，生产上热修复问题
灰度环境与生产环境共用一个master分支，当功能已经发到master后上了灰度，这时候如果线上有一个紧急的bug需要修复，master已经有当前迭代的代码，但是代码仍然在灰度环境。
-
测试过程中，代码相互交叉频率太高的问题
当某个同事正在开发某个功能，可能修改的是公共的基类，也送到test分支上测试环境测试了，但是由于开发开发了一般，代码有致命的错误，这是刚好负责的同事又休假了，整个测试环境就无法工作，要么回滚要么找同事修好要么帮他修好，也是因为不干净所导致。
支持型分支
接下来，我们的开发模式使用各种辅助分支来帮助团队成员之间的并行开发，方便追踪新特性，准备生产发布，帮助快速修复现线上产品问题。与主分支不同，这些分支总是具有有限的寿命时间，因为它们最终将被移除。
我们可能使用的不同分支有：
- Feature 分支，用于为即将发布或遥远的将来版本开发的新特性，必定会合并到dev
- Hotfix 分支，
- Release 分支
每个分支都有特定的用途，并且必须遵守严格的规则，即哪些分支可以是它们的起始分支，哪些分支必须是它们的合并目标
git分支的命名及使用规范
分支类型
- dev
- test
- master
- feat
- release
- hotfix
- docs
- chore
dev、test和master分支
- 常驻分支有：dev、test和master，dev、master必须被保护起来（不能直接push)
- dev用于开发，test分支用于测试环境，master用于生产环境
feature分支（特性分支）
命名规范
格式：feat-{jira主需求ID}-{名称}
举例：feat-YLYDZJDD-4118-plan-template
jira主需求ID，快速浏览：https://jira.mypaas.com.cn/browse/YLYDZJDD-4118
名称，一般描述分支所实现的功能
使用规范
- 由开发者从dev分支创建，最终会合并到dev或丢弃。当测试时，可以合并到test分支进行测试。
- 当功能开发完成后，需要通过gitlab的Merge Request功能进行合并。
- 当每次合并到dev之后，说明功能已经完成开发了，回归到dev之后，应当git branch -d删除（包括远端分支也要删除）。
实践
git checkout -b feature-xxx dev // coding ... git push origin feature-xxx // Merge Request // 功能开发完成后 git branch -d feature-xxx
release分支（发布分支）
命名规范
格式：release-{迭代版本号}
举例：release-202010SP1
使用规范
- 一般由测试人员从dev分支创建，并公布给团队，最终必须合并到master、dev分支
- 创建release分支的时机是：可以发灰度的时候，dev已经具备了下一个版本的已测试过的全部代码
- 当灰度测试有问题时，允许直接在该分支上修复和提交
- 由于release分支是需要上灰度环境，所以必会推送到远端，成功发生产之后，应当删除
- （可选）在合并到master分支之前，可以使用git rebase命令来美化提交历史
实践
git checkout -b release-202010SP1 dev // 灰度中... # 合并到dev git checkout dev git merge --no-ff release-202010SP1 git push origin dev # 合并到master // 使用gitlab的merge request功能 # 删除relase分支 git branch -d release-202010SP1 git branch -dr origin/release-202010SP1 git push origin release-202010SP1 --delete
hotfix分支（热修复分支）
命名规范
格式：hotfix-{jira需求ID}-{修复编号}
举例：hotfix-YLYDZJDD-4418-1
修复编号就是版本号的最后一位
强调给开发人员提bug修复，需要先提jira
使用规范
- 由开发人员从master分支创建，最终合并到master和dev
- 只在解决已在生产上的问题修复时用到，迭代开发是不需要hotfix的
- 当在灰度测试过程中，存在release分支时，hotfix分支应当合并到release分支，而不是dev
- 问题已经修复后，hotfix分支应当删除
实践
git checkout -b hotfix-xxx // fixing... # 使用gitlab的Merge Request功能合并到master # 合并到dev git checkout dev git merge --no-ff hotfix-xxx # 删除分支 git branch -d hotfix-xxx
几个场景需要注意的工作
测试场景
任何分支都可以合并到test，但是过程必不可逆。
迭代开发前的准备工作
把master分支合并到dev，防止hotfix和release分支的修复遗漏。
发布到master
每一次发布master后都需要打上标签，包括release和hotfix
标签为版本号命名：{大版本号}.{小版本号}.{修复版本号}
eg: v1.2.0
如果进行热修复，hotfix-YLYDZJDD-4418-1，更新标签为v1.2.1，重新打上标签
当有不跟迭代走的功能单独上线，{小版本号}自动加1，如v1.2.1 -> v1.3.0
当Merge Request发生冲突是的解决方法
- 直接使用线上的Resolve Conflicts功能
- 本地解决1
# 先关掉线上的合并请求, close merge request git checkout dev git pull origin dev git checkout -b conflict-feat-YLYDZJDD-4118-plan-template#dev dev git merge --no-ff feat-YLYDZJDD-4118-plan-template // resolve conflict... git push origin conflict-feat-YLYDZJDD-4118-plan-template#dev // 在使用Merge Request，把conflict-feat-YLYDZJDD-4118-plan-template#dev合并到dev
- 本地解决2
# 先关掉线上的合并请求, close merge request git checkout feature-YLYDZJDD-4118-plan-template git pull origin dev // resolve conflict... git push origin feature-YLYDZJDD-4118-plan-template // 在使用Merge Request，把feat-YLYDZJDD-4118-plan-template合并到dev
本地解决1，2的区别
原则上，我们都是feature分支合并到dev，尽可能避免逆向操作，dev会有其他人的代码会影响你当前的功能分支
使用conflict分支可以当做dev的一份拷贝，通过本地合并feature分支且解决冲突的方式，重新把已解决的代码更新到dev上即可
当不同的功能存在依赖关系时
如feat-1的功能写了一些公共的基类，可以提供feat-2使用，这时只需要吧feat-2合并到feat-1中，具体需要两个分支的开发者沟通
git提交的message规范
每次提交，Commit message 都包括三个部分：header，body 和 footer。
<type>(<scope>): <subject> <BLANK LINE> <body> <BLANK LINE> <footer>
其中，header 是必需的，body 和 footer 可以省略。
不管是哪一个部分，任何一行都不得超过72个字符（或100个字符）。这是为了避免自动换行影响美观。
git提交命令
git commit -v
Header
Header部分只有一行，包括三个字段：type（必需）、scope（可选）和subject（必需）。
type
用于说明 commit 的类别，只允许使用下面4个标识。
feat：新功能（feature）
fix：修补bug
docs：文档（documentation）
chore：构建过程、更改配置或辅助工具的变动
如果type为feat和fix，则该 commit 将肯定出现在 Change log 之中。其他情况（docs、chore）由你决定，要不要放入 Change log，建议是不要。
注意，此处的标识，像极了分支的类型，少了一个release。
要知道release作为type是不代表什么意义，因为当我们在release上进行提交时的场景是：代码已经上灰度了，然后需要进行小问题修复时，会在release分支上进行，而提交是的type应该为hotfix
scope
scope用于说明 commit 影响的范围，比如数据层、控制层、视图层等等，视项目不同而不同。
例如php会有：controller、service、repositories等，后序由团队商定
如果你的修改影响了不止一个scope，你可以使用*代替。
subject
subject是 commit 目的的简短描述，不超过50个字符。
其他注意事项：
以动词开头，比如新增，修改等
Body
（支持markdown格式文本）
Body 部分是对本次 commit 的详细描述，可以分成多行。下面是一个范例。
实现进度计划相关任务与完成条件合并 - 删除完成条件的逻辑 - 从相关任务的角度对进度节点进行清洗
有两个注意点:
- 永远别忘了第2行是空行
- 应该说明代码变动的动机，以及与以前行为的对比。
- 多个功能点应该以列表的形式描述
Footer
没有要求，只作为备注使用
git流程操作小结
# 迭代开始 // Merge Request: master -> dev git checkout dev git pull origin dev # 需求：YLYDZJDD-4118实现 git checkout -b feature-YLYDZJDD-4118-plan-template dev // coding... # 测试功能实现 git checkout test git pull origin test git merge --no-ff feature-YLYDZJDD-4118-plan-template git push origin test // testing... # 完成开发 git commit -v // 注意commit message规范 git push origin feature-YLYDZJDD-4118-plan-template // Merge Request: feature-YLYDZJDD-4118-plan-template ->dev # 解决冲突 // 线上直接解决 // 本地解决1 # 先关掉线上的合并请求, close merge request git checkout dev git pull origin dev git checkout -b conflict-feat-YLYDZJDD-4118-plan-template#dev dev git merge --no-ff feat-YLYDZJDD-4118-plan-template // resolve conflict... git push origin conflict-feat-YLYDZJDD-4118-plan-template#dev // 在使用Merge Request，把conflict-feat-YLYDZJDD-4118-plan-template#dev合并到dev // 本地解决2 # 先关掉线上的合并请求, close merge request git checkout feature-YLYDZJDD-4118-plan-template git pull origin dev // resolve conflict... git push origin feature-YLYDZJDD-4118-plan-template // 在使用Merge Request，把feat-YLYDZJDD-4118-plan-template合并到dev # 灰度测试（已经准备好了） git checkout dev git pull origin dev git checkout -b release-202010SP2 dev git push origin release-202010SP2 # 灰度时修复小问题 git checkout release-202010SP2 // fix bug... git commit -v // 注意commit message规范(type: fix) git push origin release-202010SP2 # 正式发布 // Merge Request: release-202010SP2 -> master // tag v1.2.0 # 热修复 git checkout master git pull origin master git checkout -b hotfix-YLYDZJDD-4418-1 master // fixing.. git commit -v // 注意commit message规范（type: fix） git push origin hotfix-YLYDZJDD-4418-1 // Merge Request: hotfix-YLYDZJDD-4418-1 -> master // tag v1.2.1
标签：git,流程,dev,GIT,master,release,YLYDZJDD,协作,分支 From： https://www.cnblogs.com/youqiancheng/p/17617481.html