Git flow流程介绍之我的理解（结合实际）
一、背景
本文讲述git flow的使用，除了git flow，还有github flow和gitlab flow，感兴趣的话可以自己查资料。
用到的工具：https://learngitbranching.js.org/?NODEMO=&locale=zh_CN
二、前提交代
有两个分支是长期分支，所谓长期分支，不是用完就删、是长期存在的分支
- master（有些地方叫main）
- develop（可适简化为dev）
辅助分支，或者叫临时分支，用完在特定某个时间会删掉
- feature
- release
- hotfix
除此以外，可能会有一些别的常见的分支，这些分支和git flow用到的分支无关，因为常见所以列一下
- bugfix：不知道具体什么含义，跟hotfix一样的用途吗？
- test：这分支可能是用于测试阶段的，但git flow根本不要这个分支，可用release分支替代
补充说明：
-
develop分支，按正常的流程的话，应该是和master一致的代码状态，即处于相同的commit id或revision（理想状态）
（commit id在有些情况下会被称为revision，两个概念是相同的，注意本文可能会混着概念说）
三、git flow 流程
先假定现在的代码状态如下
注意，这里main分支就是master分支，本文描述为master分支（因为这款在线git应用程序没法将main删除用master替代）。
目前的状态是：
1、master分支和develop分支具有相同的代码状态（都在c7）
2、目前线上部署的版本是v1.1版本，部署后会打tag，这个tag在c7上
在以上的初始状态下，我们来描述下git flow的流程，现在打算开发一个需求，包含几个功能：a、b、c
-
从master/develop中拉出三个分支feature_a/feature_b/feature_c，如下图
这里基于哪个分支拉出新分支都可以，因为起点相同，但假设因为某些原因导致master和develop处在不同revision，这时就得考虑要基于哪个分支进行开发，一般来说是基于最新的分支
-
这时 feature_a/b/c分支独立开发，一般不同feature分支交给不同开发人员
这是理想状态下各自开发各自的，其实实际开发过程a/b/c功能可能有共同依赖的话，比如，都要引入某个jar，或都要用到某个公共的新开发的方法，这时如果a/b/c都重复做一遍就显得有点笨拙，这种情况具体问题具体解决；也有一种可能是feature_b的一个功能需要依赖feature_a，这也不得不导致feature_a必须先提交代码（假设feature_a和b在相同的java project里头的话，如果在不同的project可以mvn deploy到公司私库来解决依赖），这些问题都是具体问题具体解决。
-
feature_a/b/c各自进行了一些开发，提交了一些代码
-
接着，a/b/c功能都开发且自测完了。c功能放弃上线，a和b要上线，所以提交MR（或PR）给开发负责人请求feature_a/b分支合并到develop以便进一步在开发环境部署并进行集成测试（开发人员在UI上点一点功能测一下，因为之前可能都仅仅是单元测试或仅使用postman测试）
- MR/PR是Merge Request或Pull Request，发起MR/PR的意思是发起一个请求单，要求将某个源分支合并到某个目标分支，这个流程是为了开发负责人能够进行code review（代码审查）和控制提交如develop分支的代码
- 批准合并可以使用自动合并功能（在GitHub或gitlab等工具上都有自动合并的按钮），自动合并在遇到冲突时，需要人员接入，由于开发负责人对具体的代码熟悉度不如开发代码的人，各个开发自行解决
合并后是如下的图：
-
用develop分支，在开发环境部署并进行开发环境的集成测试，这里有许多灵活的流程
- 要不要将develop合并到自己的feature_a/b，并在feature_a/b上修复测出的bug，修复完后再次提MR/PR合并到develop，然后再次部署再次进行测试？（感觉有点繁琐）
- 个人认为也可以让开发人员（开发a/b功能的）直接拉出本地的develop分支，在本地develop上修复此阶段发现的bug，然后提MR/PR的，要求本地的develop合并到远程的develop （个人推荐，比较简化）
- 我怀疑开发负责人真的有时间每次都code review吗？实际这个流程在实际中是经常会被跳过代码审查而直接批准合并（时间不允许时，建议抽查即可）
- 这个环节，即开发环境进行集成测试的环节，在一些公司很可能都会被省略而直接部署给QA
-
进入QA测试环节，提测。开发负责人或QA从develop拉出release分支（具体的话可以带上此次上线的版本号，比如此次要上线v2.0，则命名为 release-v2.0，用这个分支部署给QA进行测试 （开发负责人或QA去做这个事情，在完成部署release后由开发负责人发提测邮件）
-
对release分支的测试过程肯定也会发现bug，那是如何的流程？
可以二选一（非常建议QA才有权限批准develop合并到release分支，QA要控制自己测试的东西是自己预期的，不然开发人员（包括开发负责人）可以随意将代码合到release分支就不好管理了！！包括测试的数据库必须由QA来掌握是否能执行DDL甚至是删改数据，开发人员只能查测试库的数据），以下流程二选一：
- 由于feature_a/b分支已经合并了develop，是a这个功能的bug就在feature_a上修复并提交MR/PR合并到develop，在开发环境自测通过后再MR/PR合并到release分支(release-v2.0)，再次用release分支部署让QA测试
- 直接在本地develop分支修复bug，修复完毕后提MR/PR合并到develop，部署开发分支验证通过后再提MR/PR合并到release分支(release-v2.0) （推荐）
-
此时有个意外，线上出了问题，需要紧急修复并上线（不紧急的可以不需要这个流程，留在此次迭代中修复或安排在再下一次也行）
基于线上v1.1版本，从v1.1的tag中拉出hotfix分支，具体的名字可以叫做 hotfix-v1.2（表示上线后叫v1.2版本），开发人员基于hotfix-v1.2进行修复
- 可能有些公司的部署环境不足得借用下测试环境进行测试，即测试环境从原来部署的release-v2.0分支，切换成部署hotfix-v1.2分支的代码并进行测试（如线上bug涉及到某些表需要恢复到v1.1版的结构，则需要恢复一下，比如v2.0改了a、b两表的结构，bug涉及到b表，则a表不用动，将a表备份表结构和数据为a_bak，然后将a恢复表结构，待测完patch完后再将a删除将a_bak恢复为a）
- 如果有专门用于测试已发布版本的环境（比如预发布环境），可以用预发布环境测此次patch。（这也提醒了一点，上线后不仅仅是要有上线的时候的代码（v1.1这个tag所表示的代码状态），也要有相应版本的数据库结构的备份）
上线之后，代码要合并到master分支并打上tag，比如v1.2版本，如图
-
突发事件结束，需要保证此次v2.0上线也要包含刚刚的hotfix的修复，即release-v2.0要包含hotfix-1.2的改动
请求develop合并到release-v2.0分支，得到如下图
-
假如此时没有bug了，可发布，则发布后需要合并到master并打上v2.0的tag
可以看到在c16的点上发布的v2.0版本，打了tag，并且master/develop再次保证了一致
-
删掉无用的临时分支：release/hotfix/feature
feature_c留不留呢？看自己需要了，本身 “开发了的功能不要掉” 这是一种浪费在实际中也比较少见，而且这个分支留着久了会导致越来越没有价值，因为后面代码不断迭代代码的变化会比较大，将feature_c合入就会有很多冲突或者功能根本不适用了
删掉临时分支后如下：
