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模式流程介绍
1）初始化项目为GitFlow, 默认创建master分支 , 然后从master拉取第一个develop分支；
2）从develop拉取feature分支进行编码开发(多个开发人员拉取多个feature同时进行并行开发 , 互不影响)；
3）feature分支完成后 , 合并到develop(不推送 , feature功能完成还未提测 , 推送后会影响其他功能分支的开发)， 合并feature到develop , 可以选择删除当前feature , 也可以不删除 . 但当前feature就不可更改了 , 必须从release分支继续编码修改；
4）从develop拉取release分支进行提测 , 提测过程中在release分支上修改BUG；
5）release分支上线后 , 合并release分支到develop/master并推送，合并之后 , 可选删除当前release分支 , 若不删除 , 则当前release不可修改 . 线上有问题也必须从master拉取hotfix分支进行修改；
6）上线之后若发现线上BUG , 从master拉取hotfix进行BUG修改；
7）hotfix通过测试上线后 , 合并hotfix分支到develop/master并推送。合并之后 , 可选删除当前hostfix , 若不删除 , 则当前hotfix不可修改 , 若补丁未修复 , 需要从master拉取新的hotfix继续修改；
8）当进行一个feature时 , 若develop分支有变动 , 如其他开发人员完成功能并上线 , 则需要将完成的功能合并到自己分支上。即合并develop到当前feature分支；
9）当进行一个release分支时 , 若develop分支有变动 , 如其他开发人员完成功能并上线 , 则需要将完成的功能合并到自己分支上。即合并develop到当前release分支 (!!! 因为当前release分支通过测试后会发布到线上 , 如果不合并最新的develop分支 , 就会发生丢代码的情况)
2.3 GitFlow在当下敏捷开发中的弊端
GitFlow的创始人文森特·德里森在2020年3月5日写下了自己的反思note，他说自己的这个模式太过于久远，而且开发模式从传统开发转型成现在的敏捷开发，这一套流程已经不太适用了，所以请使用者参考自己系统的背景，选择更适合自己的。
2.4 其他现有工作流
那既然GitFlow已经不适合我们敏捷开发了，有没有其他的工作流模式呢？有。
而下面这两种工作流模式就是敏捷开发的优秀实践：
2.4.1 GitHub flow
2.4.2 GitLab Flow
3 我们团队的Git工作流
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上提交代码，需要将分支加以保护；
2）test分支上有大量分支存在，一旦某个分支测试阶段出现重大缺陷需要回滚，无法回滚，这种问题需要主程序员拉齐所有开发人员，删除test分支重新维护；
3）测试直接上test环境进行测试，当其中某一个环节卡住的时候，后续流程都会卡在那里，影响测试效率，这种问题现在只能快速推进问题修复；
4）测试环境不稳定，经常有人修复了bug后正在重启；
5）uat阶段的bug经常只合并到uat，test会被遗漏，导致uat上修改的问题被测试再次提出，甚至有的会很久之后才发现；
6）分支没有删除，导致git分支爆炸；
7）每次上线需要合并好几个分支，每个分支还可能会有一些sql、配置、权限等，容易遗漏。
这些问题目前都是要主程序员做好把控，具体问题具体分析处理的。
3.3 目前可以做的Git工作流优化
1）git分支保护，将master分支保护起来，任何人不得直接提交，包括主程序员以及拥有者，每个项目只给对应的两三个项目负责人合并权限，其余人需要提交merge request进行申请合并。（有些公司test也做了保护，目的是为了提测前强制review）
2）uat阶段的bug必须首先合并到test，在test上经由测试人员验证之后再合并到uat，因为uat毕竟相当于线上分支，一些bug可能会影响到正式数据。（即使出现紧急情况必须马上发uat给业务人员验证，也必须同时合并到test分支）
3）已上线分支由开发人员及时删除。或者统一记录到对应的joyspace上，由主程序员定期删除joyspace记录的过期分支。或者主程序员进行合并到dev分支的时候，在merge request上勾选删除原分支的选项。
4）开发人员维护开发数据库，不直接连接测试数据库，除非排查问题的时候，防止出现sql遗漏问题。
将测试环境的配置也模仿线上提取出的文件进行提取，防止出现配置遗漏的问题。
注：关于此处可能大家有一些疑问，我也只是给出一个建议，这一点并不是git工作流的优化，而是我们工作流程的优化。其实这个问题可以由上线的CheckList解决，而CheckList更加节约成本，对应的缺点就是对开发人员的规范要求更高，并且如果出现各种原因导致的研发变动产生的交接不完整，就会遗漏配置文件或者sql语句。我的想法是如果我们有一套框架或者系统，可以在需求开发完毕，提测的时候，能够上传sql，自动在测试库执行。增加此次维护的配置，可以自动添加到配置文件中（这个自动添加可能会导致乱序，或者改为只做记录我觉得也可），然后自动进行测试环境的编译部署。这样在上线的时候就会有参考，即使交接不完整，也可以在上线时查询到对应需求的配置修改和对应的sql语句。
3.4 Git的一些小技巧
1）merge分支之前，可以将本地未commit但确认修改无误的东西push远端，比如多个分支合并到uat分支的时候，我们可以合并一个验证完成后push，这样另一个分支合并的时候，如果冲突太多，不好解决或者不小心解决错误的时候中止合并并且硬重置，之前的工作量就不会浪费，无法启动的时候也更容易定位是哪个分支导致的。
2）如果修改test环境或者uat环境的bug时，不小心直接在test或者uat分支提交并推送了，不需要再到对应分支修改一遍，这样不仅浪费工作量，而且还容易发生冲突。合适的解决方案是直接将对应的提交cherry-pick到对应的开发分支即可。
3）git命名的时候，可以在命名中，将对应版本（如果团队在执行版本火车的话）、开发者、当前时间增加到这个分支中，形成规范，类似于“songle-20210817-xxxSignStateCheck”，便于后续管理。比如我们的分支名就是“erp-yyyyMMdd-featureName”。
4）如果一条远端分支有多人共用，那么绝对不要在上面执行reset、rebase等会修改这条分支已经存在的commit object的命令。除非你明确知道自己在做什么。
5）如果不小心在dev上开发了一些代码，还没commit，可以直接新建分支或者切回开发分支，这些未commit的修改会一起被带过去，如果切换失败了，可以先stash(贮藏)之后切换分支，然后再弹出贮藏。
4 总言
其实，协同开发的问题大大小小每个团队都有存在。而在协同开发中，既没有“金手指”，也没有“灵丹妙药”。如果想要高效、快速的实践敏捷开发，完成我们的敏捷目标，需要团队中每个人的积极参与，对现有流程查漏补缺，打磨出属于自己团队的工作流及开发规范。只有这样，才能让团队在协同开发中披荆斩棘，真正做到敏捷为生产赋能。
