疫情期间我感觉整个人懒散了不少，慢慢有意识要振作起来了，恢复到正常的节奏。最近团队代码库从Gerrit迁移到了Gitlab，为了让前端团队日常开发工作有条不紊，高效运转，开发历史可追溯，我也查阅和学习了不少资料。参考业界主流的Git工作流，结合公司业务特质，我也梳理了一套适合自己团队的Git工作流，在这里做下分享。

分支管理

首先要说的是分支管理，分支管理是git工作流的基础，好的分支设计有助于规范开发流程，也是CI/CD的基础。

分支策略

业界主流的git工作流，一般会分为develop, release, master, hotfix/xxx, feature/xxx等分支。各个分支各司其职，贯穿了整个开发，测试，部署流程。我这里也基于主流的分支策略做了一些定制，下面用一张表格简单概括下：

一般来说，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的步骤与开发需求类似，这里简单说下步骤：

1. 在Gitlab上创建issue

   创建issue，并附上TAPD上的缺陷链接，方便追溯

2. 创建分支&修复缺陷

   基于develop分支创建分支：

   // 3是issue号
   git checkout -b bug/3 origin/develop
   复制代码

   接着改代码......

3. 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
   复制代码

4. 发起Merge Request

   开发人员发起Merge Request，请求将自己修复缺陷引入的代码合入develop分支。

   然后Maintainer需要Review代码，同意本次Merge Request。

5. 等待回归测试

   该bug将在下一次CI/CD后，进入回归测试流程。

6. 级别高的测试环境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的步骤是什么呢？

1. 创建issue，标题可以从TAPD中的Bug单中copy过来，而描述就贴上Bug单的链接即可。

2. 基于master分支创建分支hotfix/5。

   git checkout -b hotfix/5 origin/master
   复制代码

3. 撸代码，修复此bug......

4. 修复完此bug后，提交该分支代码到远程仓库同名分支

   git push origin HEAD
   复制代码

5. 然后发起cherry pick合入到master和develop分支，并在master分支打上新的版本tag（假设当前最大的tag是1.0.0，那么新的版本tag应为1.0.1）。

修复线上旧版本bug

fix/6，一个线上旧版本修复分支，对应issue 6

某些项目产品可能会有多个线上版本同时在运行，那么不可避免要解决旧版本的bug。针对线上旧版本出现的bug，修复步骤与上节类似。

1. 创建issue，描述清楚问题

2. 假设当前版本是1.0.0，而0.9.0版本出了一个bug，应基于tag 0.9.0创建fix分支。

   git checkout -b fix/6 0.9.0
   复制代码

3. 修复缺陷后，应打上新的tag 0.9.1，并推送到远程。

   git tag 0.9.1
   git push origin tag 0.9.1
   复制代码

4. 如果此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还是有很多隐藏的坑的，使用起来要慎重！在这里先挖个坑吧，后面搞懂了再填坑......

注意事项

1. 一般而言，自己发起的Merge Request必须由别的同事Review并同意合入，这样更有利于发现代码问题。
2. 对了，TAPD还支持与Gitlab协同的。详情见源码关联指引。

结语

实践证明，这套Git工作流目前能覆盖我项目开发过程中的绝大部分场景。不过要注意的是，适合自己的才是最好的，盲目采用别人的方案有时候是会水土不服的。

以上所述纯属前端小微团队内部的Gitlab实践，必然存在着很多不足之处，如有错误之处还请指正，欢迎交流。