分支模型
集中式的分支模型
目前团队使用的模式属于老旧的集中式分支模型，简单的总结就是：
开发时： 团队的所有成员都在dev分支上开发（也支持少部分的特性分支feature-xxx）。
测试时： 当功能需要上测试环境测试时，把dev合并到test分支，使用test分支在测试环境中测试。
灰度时： 在发布到生产环境之前，需要经过灰度发布，此时需要把测试通过后的dev分支合并到master，灰度环境使用master分支进行灰度测试。
生产时： 最后在灰度环境也确保没问题后，直接把master发布到生产环境。
优点
操作容易
简单高效
弊端也显然易见
迭代计划内的功能临时说这版本不发或者计划内完成不了
当一个功能已经在开发当中，没有使用feature分支来开发，已经进入dev分支，然而可能由于预估时间太短，或者是逻辑没想清楚，在迭代期内无法完成，或者临时说此功能不要上，这时候还要把dev的代码清理掉，从某种意义上说dev已经被不必要的代码污染了，会增加风险。
灰度发布过程中，生产上热修复问题
灰度环境与生产环境共用一个master分支，当功能已经发到master后上了灰度，这时候如果线上有一个紧急的bug需要修复，master已经有当前迭代的代码，但是代码仍然在灰度环境。
测试过程中，代码相互交叉频率太高的问题
当某个同事正在开发某个功能，可能修改的是公共的基类，也送到test分支上测试环境测试了，但是由于开发开发了一般，代码有致命的错误，这是刚好负责的同事又休假了，整个测试环境就无法工作，要么回滚要么找同事修好要么帮他修好，也是因为不干净所导致。
支持型分支
接下来，我们的开发模式使用各种辅助分支来帮助团队成员之间的并行开发，方便追踪新特性，准备生产发布，帮助快速修复现线上产品问题。与主分支不同，这些分支总是具有有限的寿命时间，因为它们最终将被移除。
我们可能使用的不同分支有：
每个分支都有特定的用途，并且必须遵守严格的规则，即哪些分支可以是它们的起始分支，哪些分支必须是它们的合并目标
it分支的命名及使用规范
分支类型
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删除（包括远端分支也要删除）。
实践
1
2
3
4
5
6
7 | 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命令来美化提交历史
实践
1
2
3
4
5
6
7
8
9
10
11
12
13
14 | 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分支应当删除
实践
1
2
3
4
5
6
7
8
9
10
11 | 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
1
2
3
4
5
6
7
8 | # 先关掉线上的合并请求, 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
1
2
3
4
5
6 | # 先关掉线上的合并请求, 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。
1
2
3
4
5 | <type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer> |
其中，header 是必需的，body 和 footer 可以省略。
不管是哪一个部分，任何一行都不得超过72个字符（或100个字符）。这是为了避免自动换行影响美观。
git提交命令
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 的详细描述，可以分成多行。下面是一个范例。
1
2
3
4 | 实现进度计划相关任务与完成条件合并
- 删除完成条件的逻辑
- 从相关任务的角度对进度节点进行清洗 |
有两个注意点:
永远别忘了第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
本文作者:CIO之家的朋友 来源:CIO之家的朋友们
CIO之家 www.ciozj.com 微信公众号:imciow