前端小微团队的Gitlab实践
疫情期间我感觉整个人懒散了不少,慢慢有意识要振作起来了,恢复到正常的节奏。最近团队代码库从Gerrit
迁移到了Gitlab
,为了让前端团队日常开发工作有条不紊,高效运转,开发历史可追溯,我也查阅和学习了不少资料。参考业界主流的Git工作流,结合公司业务特质,我也梳理了一套适合自己团队的Git工作流,在这里做下分享。
分支管理
首先要说的是分支管理,分支管理是git
工作流的基础,好的分支设计有助于规范开发流程,也是CI/CD
的基础。
分支策略
业界主流的git
工作流,一般会分为develop
, release
, master
, hotfix/xxx
, feature/xxx
等分支。各个分支各司其职,贯穿了整个开发,测试,部署流程。我这里也基于主流的分支策略做了一些定制,下面用一张表格简单概括下:
分支名 | 分支定位 | 描述 | 权限控制 |
---|---|---|---|
develop | 开发分支 | 不可以在develop分支push代码,应新建feature/xxx进行需求开发。迭代功能开发完成后的代码都会merge到develop分支。 | Develper不可直接push,可发起merge request |
feature/xxx | 特性分支 | 针对每一项需求,新建feature分支,如feature/user_login,用于开发用户登录功能。 | Develper可直接push |
release | 提测分支 | 由develop分支合入release分支。ps: 应配置此分支触发CI/CD,部署至测试环境。 | Maintainer可发起merge request |
bug/xxx | 缺陷分支 | 提测后发现的bug,应基于develop 分支创建bug/xxx 分支修复缺陷,修改完毕后应合入develop分支等待回归测试。 |
|
master | 发布分支 | master应处于随时可发布的状态,用于对外发布正式版本。ps: 应配置此分支触发CI/CD,部署至生产环境。 | Maintainer可发起merge request |
hotfix/xxx | 热修复分支 | 处理线上最新版本出现的bug | Develper可直接push |
fix/xxx | 旧版本修复分支 | 处理线上旧版本的bug | Develper可直接push |
一般来说,develop
, release
, master
分支是必备的。而feature/xxx
, bug/xxx
, hotfix/xxx
, fix/xxx
等分支纯属一种语义化的分支命名,如果要简单粗暴一点,这些分支可以不分类,都命名为issue/issue号
,比如issue/1
,但是要在issue
中说明具体问题和待办事项,保证开发工作可追溯。
保护分支
利用Protected Branches
,我们可以防止开发人员错误地将代码push
到某些分支。对于普通开发人员,我们仅对develop
分支提供merge
权限。
具体操作案例请前往下面的实战案例一节查看。
issue驱动工作
我们团队采用的敏捷开发协作平台是腾讯的TAPD,日常迭代需求,缺陷等都会在TAPD
上记录。为了让Gitlab
代码库能与迭代日常事务关联上,我决定用Gitlab issues
来做记录,方便追溯问题。
里程碑
里程碑Milestone可以认为是一个阶段性的目标,比如是一轮迭代计划。里程碑可以设定时间范围,用来约束和提醒开发人员。
里程碑可以拆解为N个issue,新建issue
时可以关联里程碑。比如这轮迭代一共5个需求,那么就可以新建5个issue
。在约定的时间范围内,如果一个里程碑关联的所有issue
都Closed
掉了,就意味着目标顺利达成。
标签
Gitlab
提供了label
来标识和分类issue
,我觉得这是一个非常好的功能。我这里列举了几种label
,用来标识issue
的分类和紧急程度。
issue分类
所有的开发工作应该通过issue
记录,包括但不限于需求,缺陷,开发自测试,用户体验等范畴。
需求&缺陷
这里大概又分为两种情况,一种是TAPD
记录在案的需求和缺陷,另一种是与产品或测试人员口头沟通时传达的简单需求或缺陷(小公司会有这种情况…)。
对于TAPD
记录的需求和缺陷,创建issue
时应附上链接,方便查阅(上文中已有提到)。
对于口头沟通的需求和缺陷,我定了个规则,要求提出人本人在Gitlab
上创建issue
,并将需求或缺陷简单描述清楚,否则口头沟通的开发工作我不接(也是为了避免事后扯皮)。
ps:其实要求产品或者测试提issue
,还不如上Tapd
记录。我定这么个规则,其实就是借Gitlab
找个说辞,杜绝口头类需求或缺陷,哈哈。
开发自测试
开发者自己发现了系统缺陷或问题,此时应该通过issue
记录问题,并创建相应分支修改代码。
实战案例
我前面也说了,我的原则是issue
驱动开发工作。
下面用几个例子来简单说明基本的开发流程。小公司里整个流程比较简单,没有复杂的集成测试,多轮验收测试,灰度测试等。我甚至连单元测试都没做(捂脸…)。
公共库和公共组件其实是很有必要做单元测试的,这里立个flag,后面一定补上单元测试。
需求开发
feature/1,一个特性分支,对应issue 1
创建需求
正常的需求当然来源于产品经理等需求提出方,由于是通过示例说明,这里我自己在TAPD
上模拟着写一个需求。
创建issue
创建Gitlab issue
,链接到TAPD
中的相关需求。
创建分支&功能开发
基于develop
分支创建feature
分支进行功能开发(要保证本地git仓库当前处于develop分支,且与远程仓库develop分支同步)。
git checkout -b feature/1
或者直接以远程仓库的develop
分支为基础创建分支。
git checkout -b feature/1 origin/develop
ps:我这里用的feature/1
作为分支名,其实这里的1
是用的issue
号,并没有用诸如feature/login_verify
之类的名字,是因为我觉得用issue
号可以更方便地找到对应的issue
,更容易追踪代码。
接着我们开始开发新功能……
commit & push
完成功能开发后,我们需要提交代码并同步到远程仓库。
PS D:\projects\gitlab\project_xxx> git add .
PS D:\projects\gitlab\project_xxx> git cz
cz-cli@4.0.3, cz-conventional-changelog@3.1.0
? Select the type of change that you\'re committing: feat: A new feature
? What is the scope of this change (e.g. component or file name): (press enter to skip)
? Write a short, imperative tense description of the change (max 94 chars):
(9) 登录校验功能
? Provide a longer description of the change: (press enter to skip)
? Are there any breaking changes? No
? Does this change affect any open issues? Yes
? If issues are closed, the commit requires a body. Please enter a longer description of the commit itself:
-
? Add issue references (e.g. "fix #123", "re #123".):
fix #1
git push origin HEAD
git cz
是利用了commitizen
来替代git commit
。详情请点击前端自动化部署的深度实践深入了解。
fix #1
用于关闭issue 1
。
git push origin HEAD
则代表推送到远程仓库同名分支。
创建Merge Request
开发人员发起Merge Request
,请求将自己开发的功能特性合入develop
分支。
接着Maintainer
需要Review代码,确认无误后同意Merge。然后这部分代码就在远程Git
仓库入库了,其他开发同学拉取develop
分支就能看到了。
版本提测
issue/2,处理更新日志,版本号等内容,对应issue 2
每个团队的开发节奏都不同,有的团队会每日持续集成发版本提测,有的可能两天一次,这个就不深入讨论了……
那么当我们准备提测时,应该怎么做呢?
通过上节的了解,我们已经知道,迭代内的功能需求都会通过feature/xxx
分支合入到develop
分支。
提测前,一般来说,还是要更新下CHANGELOG.md
和package.json
的版本号,可以由Maintainer
或其他负责该项事务的同学执行。
主要是执行npm version major/minor/patch -m \’something done\’,具体操作可以参考前端自动化部署的深度实践一文。
git checkout -b issue/2 origin/develop
npm version minor -m \'迭代1第一次提测\'
git push origin HEAD
然后发起merge request合入develop分支
此时,应以最新的develop
分支代码在开发环境跑一遍功能,保证版本自测通过。
提测时,由Maintainer
发起Merge Request
,将develop
分支代码合入release
分支,此时自动触发Gitlab CI/CD
,自动构建并发布至测试环境。
版本提测后,各责任人应在TAPD
上将相关需求和缺陷的状态变更为“测试中”。
修复测试环境bug
bug/3,一个bug分支,对应issue 3
这里说的是在迭代周期内由测试工程师发现的测试环境中的系统bug
,这些bug
会被记录在敏捷开发协作平台TAPD
上。修复测试环境bug
的步骤与开发需求类似,这里简单说下步骤:
-
在Gitlab上创建issue
创建issue,并附上TAPD上的缺陷链接,方便追溯
-
创建分支&修复缺陷
基于
develop
分支创建分支:// 3是issue号 git checkout -b bug/3 origin/develop
接着改代码……
-
commit & push
PS D:\projects\gitlab\project_xxx> git cz cz-cli@4.0.3, cz-conventional-changelog@3.1.0 ? Select the type of change that you\'re committing: fix: A bug fix ? What is the scope of this change (e.g. component or file name): (press enter to skip) ? Write a short, imperative tense description of the change (max 95 chars): (11) 修复一个测试环境bug ? Provide a longer description of the change: (press enter to skip) ? Are there any breaking changes? No ? Does this change affect any open issues? Yes ? If issues are closed, the commit requires a body. Please enter a longer description of the commit itself: - ? Add issue references (e.g. "fix #123", "re #123".): fix #3 git push origin HEAD
-
发起Merge Request
开发人员发起
Merge Request
,请求将自己修复缺陷引入的代码合入develop
分支。然后
Maintainer
需要Review代码,同意本次Merge Request
。 -
等待回归测试
该
bug
将在下一次CI/CD
后,进入回归测试流程。 -
级别高的测试环境Bug
如果是级别很高的
bug
,比如影响了系统运行,导致测试人员无法正常测试的,应以release
分支为基础创建bug
分支,修改完毕后合入release
分支,再发起cherry pick
合入develop
分支。
发布至生产环境
经过几轮持续集成和回归测试后,一个迭代版本也慢慢趋于稳定,此时也迎来了激动人心的上线时间。我们要做的就是把通过了测试的release
分支合入master
分支。
这一步相对简单,但是要特别注意权限控制(防止生产环境事故),具体权限控制可以回头看第一章节分支管理。
与release
分支类似,master
分支自动触发Gitlab CI/CD
,自动构建并发布至生产环境。
线上回滚
revert/4,一个回滚分支,对应issue 4
代码升级到线上,但是发现报错,系统无法正常运行。此时如果不能及时排查出问题,那么只能先进行版本回退操作。
先说说惯性思维下,我的版本回退做法。
首先还是创建issue
记录下:
基于master
分支创建revert/4
分支
git checkout -b revert/4 origin/master
假设当前版本是1.1.0
,我们想回退到上个版本1.0.3
。那么我们需要先查看下1.0.3
版本的信息。
PS D:\tusi\projects\gitlab\projectname> git show 1.0.3
commit 90c9170a499c2c5f8f8cf4e97fc49a91d714be50 (tag: 1.0.3, fix/1.0.2_has_bug)
Author: tusi <tusi@xxx.com.cn>
Date: Thu Feb 20 13:29:31 2020 +0800
fix:1.0.2
diff --git a/README.md b/README.md
index ac831d0..2ee623b 100644
--- a/README.md
+++ b/README.md
@@ -10,6 +10,8 @@
只想修改旧版本的bug,不改最新的master
+1.0.2版本还是有个版本,再修复下
+
特性2提交
特性3提交
主要是取到1.0.3
版本对应的commit id
,其值为90c9170a499c2c5f8f8cf4e97fc49a91d714be50
。
接着,我们根据commit id
进行reset
操作,再推送到远程同名分支。
git reset --hard 90c9170a499c2c5f8f8cf4e97fc49a91d714be50
git push origin HEAD
接着发起Merge Request
把revert/4
分支合入master
分支。
一般来说,这波操作没什么问题,能解决常规的回滚问题。
临时变通
由于master
分支是保护分支,设置了不可push
。如果不想通过merge
的方式回滚,所以只能先临时设置Maintainer
拥有push
权限,然后由Maintainer
进行回滚操作。
git checkout master
git pull
git show 1.0.3
git reset --hard 90c9170a499c2c5f8f8cf4e97fc49a91d714be50
git push origin HEAD
完事后,还需要记得把master
设置为不可push
。
Q: 为什么不让
Maintainer
一直拥有master
的push
权限?A: 主要还是为了防止出现生产环境事故,给予临时性权限更稳妥!
git reset –hard存在什么问题?
如题,git reset --hard
确实是存在问题的。git reset --hard
属于霸道玩法,直接移动HEAD
指针,会丢弃之后的提交记录,如果不慎误操作了也别慌,还是可以通过查询git reflog
找到commitId
抢救回来的;git reset
后还存在一个隐性的问题,如果与旧的branch
进行merge
操作时,会把git reset
回滚的代码重新引入。那么怎么解决这些问题呢?
别慌,这个时候你必须掏出git revert
了。
Q:
git revert
的优势在哪?A: 首先,
git revert
是通过一次新的commit来进行回滚操作的,HEAD指针向前移动,这样就不会丢失记录;另外,git revert
也不会引起merge
旧分支时误引入回滚的代码。最重要的是,git revert
在回滚的细节控制上更加优秀,可解决部分回滚的需求。
举个栗子,本轮迭代团队共完成需求2
项,而上线后发现其中1
项需求有致命性缺陷,需要回滚这个需求相关的代码,同时要保留另一个需求的代码。
首先我们查看下日志,找下这两个需求的commitId
PS D:\tusi\projects\test\git_test> git log --oneline
86252da (HEAD -> master, origin/master, origin/HEAD) 解决冲突
e3cef4e (origin/release, release) Merge branch \'develop\' into \'release\'
f247f38 (origin/develop, develop) 需求2
89502c2 需求1
我们利用git revert
回滚需求1相关的代码
git revert -n 89502c2
这时可能要解决冲突,解决完冲突后就可以push
到远程master
分支了。
git add .
git commit -m \'回滚需求1的相关代码,并解决冲突\'
git push origin master
感觉还是菜菜的,如果大佬们有更优雅的解决方案,求指导啊!
修复线上bug
hotfix/5,一个线上热修复分支,对应issue 5
比如线上出现了系统无法登录的bug
,测试工程师也在TAPD
提交了缺陷记录。那么修复线上bug
的步骤是什么呢?
-
创建
issue
,标题可以从TAPD
中的Bug
单中copy
过来,而描述就贴上Bug
单的链接即可。 -
基于
master
分支创建分支hotfix/5
。git checkout -b hotfix/5 origin/master
-
撸代码,修复此bug……
-
修复完此
bug
后,提交该分支代码到远程仓库同名分支git push origin HEAD
-
然后发起
cherry pick
合入到master
和develop
分支,并在master
分支打上新的版本tag
(假设当前最大的tag
是1.0.0
,那么新的版本tag
应为1.0.1
)。
修复线上旧版本bug
fix/6,一个线上旧版本修复分支,对应issue 6
某些项目产品可能会有多个线上版本同时在运行,那么不可避免要解决旧版本的bug
。针对线上旧版本出现的bug
,修复步骤与上节类似。
-
创建
issue
,描述清楚问题 -
假设当前版本是
1.0.0
,而0.9.0
版本出了一个bug
,应基于tag 0.9.0
创建fix
分支。git checkout -b fix/6 0.9.0
-
修复缺陷后,应打上新的
tag 0.9.1
,并推送到远程。git tag 0.9.1 git push origin tag 0.9.1
-
如果此
bug
也存在于最新的master
分支,则需要git push origin HEAD
提交该fix
分支代码到远程仓库同名分支,然后发起cherry pick
合入到master
,此时很大可能存在冲突,需要解决冲突。
cherry pick
在了解到cherry pick
之前,我一直认为只有git merge
可以合并代码,也好几次遇到合入了不想要的代码的问题。有了cherry pick
,我们就可以合并单次提交记录,解决git merge
时合并太多不想要的内容的烦恼,在解决bug
时特别有用。
git rebase
经过这段时间的使用,我发现使用git merge
合并分支时,会让git log
的Graph
图看起来有点吃力。
PS D:\tusi\projects\gitlab\projectname> git log --pretty --oneline --graph
* 7f513b0 (HEAD -> develop) Merge branch \'issue/55\' into \'release\'
|\
| * 1c94437 (origin/issue/55, issue/55) fix: 【bug】XXX1
| * c84edd6 Merge branch \'release\' of host:project_repository into release
| |\
| |/
|/|
* | 115a26c Merge branch \'develop\' into \'release\'
|\ \
| * \ 60d7de6 Merge branch \'issue/30\' into \'develop\'
| |\ \
| | * | 27c59e8 (origin/issue/30, issue/30) fix: 【bug】XXX2
| | | * ea17250 Merge branch \'release\' of host:project_repository into release
| | | |\
| |_|_|/
|/| | |
* | | | 9fd704b Merge branch \'develop\' into \'release\'
|\ \ \ \
| |/ / /
| * | | a774d26 Merge branch \'issue/30\' into \'develop\'
| |\ \ \
| | |/ /
接着我就了解到了git rebase
,变基,哈哈哈。由于对rebase
了解不深,目前也不敢轻易改用rebase
,毕竟rebase
还是有很多隐藏的坑的,使用起来要慎重!在这里先挖个坑吧,后面搞懂了再填坑……
注意事项
- 一般而言,自己发起的
Merge Request
必须由别的同事Review
并同意合入,这样更有利于发现代码问题。 - 对了,
TAPD
还支持与Gitlab
协同的。详情见源码关联指引。
结语
实践证明,这套Git
工作流目前能覆盖我项目开发过程中的绝大部分场景。不过要注意的是,适合自己的才是最好的,盲目采用别人的方案有时候是会水土不服的。
以上所述纯属前端小微团队内部的Gitlab
实践,必然存在着很多不足之处,如有错误之处还请指正,欢迎交流。