敏捷开发下的Git工作流应用实践-京东云开发者社区

### 1 背景
在我们日常工作中，协同开发是最高效的一种方式，尤其是比较大的需求点以及功能，甚至是新项目的开发。这种情况下，Git的使用无可避免的也会出现一些问题。而在计算机技术发展到今天的同时，协同开发工具也不断进步着，向我们熟知的SVN和Git，本身就是成熟的协同开发框架。尤其是GitFlow工作流模式，更是一度被许多公司奉为协同开发的典范并纳入开发规范中。那么，今天就说一下敏捷开发过程中，我们应该使用怎样的工作流模式才能更高效的完成开发工作呢？

### 2 传统的GitFlow工作流模式
介绍一下GitFlow的工作流模式，心急的小伙伴可以直接跳到--3 我们团队的Git工作流
#### 2.1 常用分支
- **master：**
主分支 , 产品的功能全部实现后 , 最终在master分支对外发布；
该分支为只读唯一分支 , 只能从其他分支(release/hotfix)合并 , 不能在此分支修改；
另外所有在master分支的推送应该打标签做记录,方便追溯；
例如release合并到master , 或hotfix合并到master；

- **develop：**
主开发分支 , 基于master分支克隆；
包含所有要发布到下一个release的代码；
该分支为只读唯一分支 , 只能从其他分支合并；
feature功能分支完成 , 合并到develop(不推送)；
develop拉取release分支 , 提测；
release/hotfix 分支上线完毕 , 合并到develop并推送；

- **feature：**
功能开发分支 , 基于develop分支克隆 , 主要用于新需求新功能的开发；
功能开发完毕后合到develop分支(未正式上线之前不推送到远程中央仓库!!!)；
feature分支可同时存在多个 , 用于团队中多个功能同时开发 , 属于临时分支 , 功能完成后可选删除；

- **release：**
测试分支 , 基于feature分支合并到develop之后 , 从develop分支克隆；
主要用于提交给测试人员进行功能测试 , 测试过程中发现的BUG在本分支进行修复 , 修复完成上线后合并到develop/master分支并推送(完成功能) , 打Tag；
属于临时分支 , 功能上线后可选删除；

- **hotfix：**
补丁分支 , 基于master分支克隆 , 主要用于对线上的版本进行BUG修复；
修复完毕后合并到develop/master分支并推送 , 打Tag；
属于临时分支 , 补丁修复上线后可选删除；
所有hotfix分支的修改会进入到下一个release；

#### 2.2 GitFlow模式流程介绍
![](//img1.jcloudcs.com/developer.jdcloud.com/a4afc778-58d7-4453-9cab-325bb56cb44720210902141631.png)

1. 初始化项目为GitFlow, 默认创建master分支 , 然后从master拉取第一个develop分支；
1. 从develop拉取feature分支进行编码开发(多个开发人员拉取多个feature同时进行并行开发 , 互不影响)；
1. feature分支完成后 , 合并到develop(不推送 , feature功能完成还未提测 , 推送后会影响其他功能分支的开发)，合并feature到develop , 可以选择删除当前feature , 也可以不删除 . 但当前feature就不可更改了 , 必须从release分支继续编码修改；
1. 从develop拉取release分支进行提测 , 提测过程中在release分支上修改BUG；
1. release分支上线后 , 合并release分支到develop/master并推送，合并之后 , 可选删除当前release分支 , 若不删除 , 则当前release不可修改 . 线上有问题也必须从master拉取hotfix分支进行修改；
1. 上线之后若发现线上BUG , 从master拉取hotfix进行BUG修改；
1. hotfix通过测试上线后 , 合并hotfix分支到develop/master并推送。合并之后 , 可选删除当前hostfix , 若不删除 , 则当前hotfix不可修改 , 若补丁未修复 , 需要从master拉取新的hotfix继续修改；
1. 当进行一个feature时 , 若develop分支有变动 , 如其他开发人员完成功能并上线 , 则需要将完成的功能合并到自己分支上。即合并develop到当前feature分支；
1. 当进行一个release分支时 , 若develop分支有变动 , 如其他开发人员完成功能并上线 , 则需要将完成的功能合并到自己分支上。即合并develop到当前release分支 (!!! 因为当前release分支通过测试后会发布到线上 , 如果不合并最新的develop分支 , 就会发生丢代码的情况)

#### 2.3 GitFlow在当下敏捷开发中的弊端
GitFlow的创始人文森特·德里森在2020年3月5日写下了自己的反思note，他说自己的这个模式太过于久远，而且开发模式从传统开发转型成现在的敏捷开发，这一套流程已经不太适用了，所以请使用者参考自己系统的背景，选择更适合自己的。

Note of reflection (March 5, 2020) 
This model was conceived in 2010, now more than 10 years ago, and not very long after Git itself came into being. In those 10 years, git-flow (the branching model laid out in this article) has become hugely popular in many a software team to the point where people have started treating it like a standard of sorts — but unfortunately also as a dogma or panacea. 
During those 10 years, Git itself has taken the world by a storm, and the most popular type of software that is being developed with Git is shifting more towards web apps — at least in my filter bubble. Web apps are typically continuously delivered, not rolled back, and you don't have to support multiple versions of the software running in the wild. 
This is not the class of software that I had in mind when I wrote the blog post 10 years ago. If your team is doing continuous delivery of software, I would suggest to adopt a much simpler workflow (like GitHub flow) instead of trying to shoehorn git-flow into your team. 
If, however, you are building software that is explicitly versioned, or if you need to support multiple versions of your software in the wild, then git-flow may still be as good of a fit to your team as it has been to people in the last 10 years. In that case, please read on. 
To conclude, always remember that panaceas don't exist. Consider your own context. Don't be hating. Decide for yourself.
--------摘自文森特·德里森的 A successful Git branching model

#### 2.4 其他现有工作流
那既然GitFlow已经不适合我们敏捷开发了，有没有其他的工作流模式呢？有。
而下面这两种工作流模式就是敏捷开发的优秀实践：
##### 2.4.1 GitHub flow

![](//img1.jcloudcs.com/developer.jdcloud.com/13900d9b-f8c4-4bce-ada4-c24071eda31220210902142316.png)

##### 2.4.2 GitLab Flow

![](//img1.jcloudcs.com/developer.jdcloud.com/91ec9a66-3b23-437b-9ffd-24edcdf3aaa220210902142352.png)

### 3 我们团队的Git工作流

![](//img1.jcloudcs.com/developer.jdcloud.com/bdeeba54-7d09-4f5b-bf59-b385a0f946dc20210902142418.png)

### 3.1 分支介绍
- **master：**
主分支 , 产品的功能全部实现后 , 最终在master分支对外发布；
上线前由dev分支合并到此分支；

- **dev：**
除client包之外，和master完全一致，用来做备份以及打rpc的jar包；
上线前由feature-rev分支合并到此分支；

- **uat：**
灰度发布分支，用于业务上线前验证以及培训使用；
由feature-rev分支合并后进行uat灰度发布；

- **test：**
测试分支，提测后部署到测试环境，由测试人员进行测试；
由feature分支开发完成后合并到此分支进行提测。

- **feature：**
功能开发分支 , 基于dev分支克隆 , 主要用于新需求新功能的开发；
功能开发完毕后用于提测以及修改bug；
feature分支可同时存在多个 , 用于团队中多个功能同时开发 , 属于临时分支 , 功能完成后可选删除；

- **feature-rev：**
代码评审分支，开发完成后先合并到此分支进行评审，保证此分支都是评审通过的代码，然后从此分支进行向test、uat、dev分支的合并。 属于临时分支 , 功能完成后可选删除。

#### 3.2 我们工作中Git工作流可能存在的问题
1. 开发权限未做限制，所有开发者都被允许直接在master上提交代码，需要将分支加以保护；
1. test分支上有大量分支存在，一旦某个分支测试阶段出现重大缺陷需要回滚，无法回滚，这种问题需要主程序员拉齐所有开发人员，删除test分支重新维护；
1. 测试直接上test环境进行测试，当其中某一个环节卡住的时候，后续流程都会卡在那里，影响测试效率，这种问题现在只能快速推进问题修复；
1. 测试环境不稳定，经常有人修复了bug后正在重启；
1. uat阶段的bug经常只合并到uat，test会被遗漏，导致uat上修改的问题被测试再次提出，甚至有的会很久之后才发现；
1. 分支没有删除，导致git分支爆炸；
1. 每次上线需要合并好几个分支，每个分支还可能会有一些sql、配置、权限等，容易遗漏。

这些问题目前都是要主程序员做好把控，具体问题具体分析处理的。

#### 3.3 目前可以做的Git工作流优化
1. git分支保护，将master分支保护起来，任何人不得直接提交，包括主程序员以及拥有者，每个项目只给对应的两三个项目负责人合并权限，其余人需要提交merge request进行申请合并。（有些公司test也做了保护，目的是为了提测前强制review。）
1. uat阶段的bug必须首先合并到test，在test上经由测试人员验证之后再合并到uat，因为uat毕竟相当于线上分支，一些bug可能会影响到正式数据。（即使出现紧急情况必须马上发uat给业务人员验证，也必须同时合并到test分支）
1. 已上线分支由开发人员及时删除。或者统一记录到对应的joyspace上，由主程序员定期删除joyspace记录的过期分支。或者主程序员进行合并到dev分支的时候，在merge request上勾选删除原分支的选项。。
1. 开发人员维护开发数据库，不直接连接测试数据库，除非排查问题的时候，防止出现sql遗漏问题。

将测试环境的配置也模仿线上提取出的文件进行提取，防止出现配置遗漏的问题。

注：关于此处可能大家有一些疑问，我也只是给出一个建议，这一点并不是git工作流的优化，而是我们工作流程的优化。其实这个问题可以由上线的CheckList解决，而CheckList更加节约成本，对应的缺点就是对开发人员的规范要求更高，并且如果出现各种原因导致的研发变动产生的交接不完整，就会遗漏配置文件或者sql语句。我的想法是如果我们有一套框架或者系统，可以在需求开发完毕，提测的时候，能够上传sql，自动在测试库执行。增加此次维护的配置，可以自动添加到配置文件中（这个自动添加可能会导致乱序，或者改为只做记录我觉得也可），然后自动进行测试环境的编译部署。这样在上线的时候就会有参考，即使交接不完整，也可以在上线时查询到对应需求的配置修改和对应的sql语句。

#### 3.4 Git的一些小技巧
1. merge分支之前，可以将本地未commit但确认修改无误的东西push远端，比如多个分支合并到uat分支的时候，我们可以合并一个验证完成后push，这样另一个分支合并的时候，如果冲突太多，不好解决或者不小心解决错误的时候中止合并并且硬重置，之前的工作量就不会浪费，无法启动的时候也更容易定位是哪个分支导致的。
1. 如果修改test环境或者uat环境的bug时，不小心直接在test或者uat分支提交并推送了，不需要再到对应分支修改一遍，这样不仅浪费工作量，而且还容易发生冲突。合适的解决方案是直接将对应的提交cherry-pick到对应的开发分支即可。
1. git命名的时候，可以在命名中，将对应版本（如果在执行版本火车的话）、开发者、当前时间增加到这个分支中，形成规范，类似于“songle-20210817-xxxSignStateCheck”，便于后续管理。比如我们的分支名就是“erp-yyyyMMdd-featureName”。
1. 如果一条远端分支有多人共用，那么绝对不要在上面执行reset、rebase等会修改这条分支已经存在的commit object的命令。除非你明确知道自己在做什么。
1. 如果不小心在dev上开发了一些代码，还没commit，可以直接新建分支或者切回开发分支，这些未commit的修改会一起被带过去，如果切换失败了，可以先stash(贮藏)之后切换分支，然后再弹出贮藏。

### 4 总言
其实，协同开发的问题大大小小每个团队都有存在。而在协同开发中，既没有“金手指”，也没有“灵丹妙药”。如果想要高效、快速的实践敏捷开发，完成我们的敏捷目标，需要团队中每个人的积极参与，对现有流程查漏补缺，打磨出属于自己团队的工作流及开发规范。只有这样，才能让团队在协同开发中披荆斩棘，真正做到敏捷为生产赋能。

#### 参考资料
A successful Git branching model：https://nvie.com/posts/a-successful-git-branching-model/
GitHub Flow：https://guides.github.com/introduction/flow/
GitLab Flow：https://docs.gitlab.com/ee/topics/gitlab_flow.html

------------
###### 自猿其说Tech-JDL京东物流技术发展部
###### 作者：运力平台技术部 宋乐