搜索 | 会员  
GIT协作流程规范
来源: CIO之家的朋友们   作者:CIO之家的朋友  日期:2023/3/20  类别:软件项目  主题:综合  编辑:人心太涼別太善良
目前团队使用的模式属于老旧的集中式分支模型,简单的总结就是:开发时:团队的所有成员都在dev分支上开发(也支持少部分的特性分支feature-xxx)。测试时:当功能需要上测试环境测试时,把dev

分支模型

集中式的分支模型

image.png

目前团队使用的模式属于老旧的集中式分支模型,简单的总结就是:

开发时: 团队的所有成员都在dev分支上开发(也支持少部分的特性分支feature-xxx)。
测试时: 当功能需要上测试环境测试时,把dev合并到test分支,使用test分支在测试环境中测试。
灰度时: 在发布到生产环境之前,需要经过灰度发布,此时需要把测试通过后的dev分支合并到master,灰度环境使用master分支进行灰度测试。
生产时: 最后在灰度环境也确保没问题后,直接把master发布到生产环境。

优点

  1. 操作容易

  2. 简单高效

弊端也显然易见

  1. 迭代计划内的功能临时说这版本不发或者计划内完成不了

    当一个功能已经在开发当中,没有使用feature分支来开发,已经进入dev分支,然而可能由于预估时间太短,或者是逻辑没想清楚,在迭代期内无法完成,或者临时说此功能不要上,这时候还要把dev的代码清理掉,从某种意义上说dev已经被不必要的代码污染了,会增加风险。

  2. 灰度发布过程中,生产上热修复问题

    灰度环境与生产环境共用一个master分支,当功能已经发到master后上了灰度,这时候如果线上有一个紧急的bug需要修复,master已经有当前迭代的代码,但是代码仍然在灰度环境。

  3. 测试过程中,代码相互交叉频率太高的问题

    当某个同事正在开发某个功能,可能修改的是公共的基类,也送到test分支上测试环境测试了,但是由于开发开发了一般,代码有致命的错误,这是刚好负责的同事又休假了,整个测试环境就无法工作,要么回滚要么找同事修好要么帮他修好,也是因为不干净所导致。

支持型分支

接下来,我们的开发模式使用各种辅助分支来帮助团队成员之间的并行开发,方便追踪新特性,准备生产发布,帮助快速修复现线上产品问题。与主分支不同,这些分支总是具有有限的寿命时间,因为它们最终将被移除。

我们可能使用的不同分支有:

  • Feature 分支,用于为即将发布或遥远的将来版本开发的新特性,必定会合并到dev

  • Hotfix 分支,

  • Release 分支

每个分支都有特定的用途,并且必须遵守严格的规则,即哪些分支可以是它们的起始分支,哪些分支必须是它们的合并目标

image.png

it分支的命名及使用规范

分支类型

  • dev

  • test

  • master

  • feat

  • release

  • hotfix

  • docs

  • chore

dev、test和master分支

  1. 常驻分支有:dev、test和master,dev、master必须被保护起来(不能直接push)

  2. 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发生冲突是的解决方法

  1. 直接使用线上的Resolve Conflicts功能

  2. 本地解决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
  3. 本地解决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提交命令


1
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 的详细描述,可以分成多行。下面是一个范例。


1
2
3
4
实现进度计划相关任务与完成条件合并

- 删除完成条件的逻辑
- 从相关任务的角度对进度节点进行清洗


有两个注意点:

  1. 永远别忘了第2行是空行

  2. 应该说明代码变动的动机,以及与以前行为的对比。

  3. 多个功能点应该以列表的形式描述

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

德仔网尊重行业规范,每篇文章都注明有明确的作者和来源;德仔网的原创文章,请转载时务必注明文章作者和来源:德仔网;
头条那些事
大家在关注
广告那些事
我们的推荐
也许感兴趣的
干货