Git协同工作流介绍

git相关的文章和教程非常多，但是系统介绍和了解工作流的人并不多，在使用过程中用错或用偏的也不少，这里分享的是，假设你已经入门的情况下，我们如何去选择适合团队需要的工作流。

git优势

　　这里先唠叨git的优势，对比传统的代码管理工具，git至少有以下这些优点：

• 有温度的工具：由 Git 衍生出来的 GitHub/GitLab 可以帮你很好地管理编程工作，比如GitHub包括即时通信功能，开发者可以互相审核、评论和打分。同时还包括 wiki、fork、pull request、issue……集成了与编程相关的工作，让我们的工作可以呈现在一个工作平台上，并以此来规范整个团队的工作。
• 分布式管理：你可以离线提交代码，而不用担心网络问题。
• 合并分支管理：合并分支后也能查看整个代码的变更记录
• 分支快速切换：Git 切换分支的时候通常很快，不像其他版本管理器，比如SVN，每个分支一份拷贝。

git常用命令

　　跳转这里查看常用命令：常用命令

　　这里记录自己平时经常使用的一些命令，并不是本文的重点。另外叨叨一下，有些人喜欢在集成的IDE下通过界面方式来进行操作，比如vs code或者eclipse都有傻瓜化的集成，这里推荐使用命令行操作，我觉得有如下一些优势:

• 第一、可以和IDE解耦，不用换一个IDE就要去了解对应界面的使用方法；
• 第二、命令行的操作非常快速，当然缺点是你需要记忆一些命令，但是常用的命令真心不多；
• 第三、命令行拥有界面没有的体验，比如一个简单的git status你可以查看内部更多的详情；git stash命令，可以把当前没有完成的事先暂存一下，然后去忙别的事；git cherry-pick命令可以让你有选择地合并提交。git add -p可以让你挑选改动提交。

git工作流介绍

　　市面上有以下几种常见的工作流：

• 中心式协同工作流【主干开发】
• 功能分支协同工作流【特性分支】
• github协同工作流
• gitlab协同工作流
• gitflow协同工作流

中心式协同工作流

　　这种方式等于把git当做svn适用，很多同学估计都是这么用的。这种协同方式是所有的人都在 Master 分支上共享他们的代码。

流程

　　这里的流程是这样的：

• 从服务器上把代码同步下来；
• 本地编码后，再add/commit到本地仓库
• 最后再push到origin master上

　　这里的第三步有可能出错，因为可能别人在你之前在相同地方已经提交了代码，这时候你需要先(git pull --rebase)一下，如果发现冲突，就解决冲突然后继续合并(git rebase --continue)。到这里你是否感觉和svn越来越像，每天早上过来定时的update一下，然后再编码，上传代码之前也是这样先update一下，再做上传操作？

焦油坑

　　这里有几个坑需要注意：

• 代码冲突：建议每天编码之前和代码上传之前不定期、频繁的进行git pull --rebase。
• 代码干扰：随着开发团队规模的扩大，可能你pull一个不可运行的代码下来(push上去的人没有用心检查是否可以编译通过)，这时候你的麻烦开始产生了，你要停下手上的活，花费可能很久的时间去把代码编译通过，于是我们经常听到很多开发人员在那边互相抱怨，怎么就不能好好检查后再上传呢，还让不让人写代码，好好学习一下svn怎么用吧……

总结：

　　中心式的协同显然无法满足团队规模的扩展和代码的干扰冲突，而且产品上线后，master的BUG会直接影响生产环境，也就说master其实是不稳定的，而用不稳定的主干直接和生产环境挂钩，后果可想而知。所以该流程不适用产品线迭代开发和持续更新，如果你只有1-2个开发人员那就罢了，否则一般不建议使用这种方式，接下来就要介绍如何去避免上面的这些焦油坑，也就是我们的功能分支协同工作流上场了。

功能分支协同工作流

　　上面的那种方式有一个问题，就是大家都在一个主干上开发程序，对于小团队或是小项目你可以这么干，但是对比较大的项目或是人比较多的团队，这么干就会有很多问题。最大的问题就是代码可能干扰太严重。尤其是，我们想安安静静地开发一个功能时，我们想把各个功能的代码变动隔离开来，同时各个功能又会有多个开发人员在开发。

　　这时，我们不想让各个功能的开发人员都在 Master 分支上共享他们的代码。我们想要的协同方式是这样的：同时开发一个功能的开发人员可以分享各自的代码，但是不会把代码分享给开发其他功能的开发人员，直到整个功能开发完毕后，才会分享给其他的开发人员（也就是进入主干分支），接下来就是我们的功能分支上场了。

流程：

　　这里的流程是这样的：

1. 切割开发分支：从git服务器上clone一份代码下来，并在本地切割出一个分支(git checkout -b jackyfei_dev)；
2. 编码提交：在分支下进行本地编码，后进行git add和git commit;
3. 合并分支：切换到master分支(git checkout master)，合并jackyfei_dev分支(git merge jackyfei_dev)；
4. 推送到服务器：最后push到服务器(git push -u origin master)，注意这里推送后不会把分支一起推送到服务器，如果要推送分支上去可以使用命令：git push origin jackyfei_dev；
5. 代码重审或代码测试[可选步骤]：代码审查人员或代码测试人员在你的分支上审查或测试通过后，在服务器端进行合并操作。该步骤根据团队大小进行选择，非必做项。
6. 删除分支[可选步骤]：这里有点阅后即焚的感觉(git branch -d jackyfei_dev)，当然你不删除也无妨，后续可以继续使用。

切割分支：

合并分支：

推送分支：

注意事项

• 删除分支：如果你在还没合并分支的时候，就要进行分支删除操作，git会有一个提示不能删除的操作，如果有重要的代码没有合并，建议不要-D强制删除。
• 分支冲突：在合并的过程会出现冲突，如下图所示，这时候需要手动解决冲突，方式和svn一样。手动合并后，再git add/git commit就可以了。
• 版本同步：这里的master和线上的版本保持同步，所以master必须尽量保证是干净的，稳定的，一般不要轻易去动他。

焦油坑

　　这里和注意事项不同，罗列的是该协作方式的缺陷：

• 线上出现BUG，本地分支正开发到一半，还没经过测试，无法进行发布，这时该如何解决？
• master无法保证一定是纯净的，因为每个人都可以merge上去

总结：

　　我们可以看到，其实，这种开发也是以服务器为中心的开发，还不是 Git 分布式开发，它只不过是用分支来完成代码改动的隔离。这里隔离的内容不叫项目而是小功能，这符合了产品快速迭代的需求。

　　如果团队规模不大，采用这种分支协同反而可能增加不必要的工作，所以要根据团队规模和现实当中的问题进行选型，一般团队超过两个人以上，而且线上环境频繁变更导致经常性的出现不稳定的异常，这种协同方式还是挺不错的。这里要思考的是，如果线上出了问题，本地开发一半无法进行发布的问题该如何处理呢？

GitFlow协同工作流

　　针对功能分支工作流的不足，GitFlow出现了，该工作流总共有5个分支，而其中的master和developer两个分支需要长期维护，其他的分支都是可以随时“阅后即焚”的。

流程

　　这里的流程是这样的：

1. Feature 分支：也就是功能分支，用于开发功能，其对应的是开发环境，可以“阅后即焚”。
2. Developer 分支：是开发分支，一旦功能开发完成，就向Developer 分支合并，合并完成后，删除功能分支。这个分支对应的是集成测试环境。
3. Release 分支：当 Developer 分支测试达到可以发布状态时，开出一个 Release 分支来，然后做发布前的准备工作。这个分支对应的是预发环境。之所以需要这个 Release 分支，是我们的开发可以继续向前，不会因为要发布而被 block 住而不能提交。一旦 Release 分支上的代码达到可以上线的状态，那么需要把 Release 分支向 Master 分支和 Developer 分支同时合并，以保证代码的一致性。然后再把 Release 分支删除掉。
4. Hotfix 分支：是用于处理生产线上代码的 Bug-fix，每个线上代码的 Bug-fix 都需要开一个 Hotfix 分支，完成后，向 Developer 分支和 Master 分支上合并。合并完成后，删除 Hotfix 分支。
5. Master 分支：也就是主干分支，用作发布环境，上面的每一次提交都是可以发布到线上环境的。

主要事项

• 我们需要长期维护 Master 和 Developer 两个分支。
• Release 和 Hotfix 分支需要同时向两个分支作合并。所以，如果没有一个好的工具来支撑的话，这会因为我们可能会忘了做一些操作而导致代码不一致。
• GitFlow 协同虽然工作流比较重。但是它几乎可以应对所有公司的各种开发流程，包括瀑布模型，或是快速迭代模型。

焦油坑

• 分支太多，所以会出现 git log 混乱的局面。
• 在开发得足够快的时候，你会觉得同时维护 Master 和 Developer 两个分支是很太无聊，因为大部分情况下两者都是一样的。
• 管理变得非常复杂。尤其当你想回滚某些人的提交时，你就会发现这事似乎有点儿不好干了。
• 工作过程中，你会来来回回地切换工作的分支，有时候一不小心没有切换，就提交到了不正确的分支上，你还要回滚和重新提交等等。

GitHub Flow

流程

　　除非你是开源项目或者有购买github企业版，否则一般企业不会把核心代码托管在公共的github上面。

• 开发人员都把github上的代码 fork 到自己的代码仓库中。
• 开发容易代码库有两个远程仓库，一个是自己fork的库，一个是官方的库。
• 开发人员在本地建“功能分支”，在这个分支上做代码开发。
• 开发完成后，功能分支被 push 到开发人员自己的代码仓库中。
• 然后，向“官方库”发起 pull request，并做 Code Review。
• 一旦通过，就向官方库进行合并。

焦油坑

• GitHub Flow 这种玩法虽然变得很简单，但是没能把我们的代码和运行环境给联系在一起。

GitLab Flow

流程

　　以上是引入环境分支流程：

• 从master分支拉取一个预发布环境分支
• 从预发布环境分支拉取一个生产环境分支

　　流程虽然简单，但是增加分支后都是工作量，如果有很好的引入CI/CD，其实这一步也是多余的。以上主要是针对2C的互联网业务，2B的要看情况来处理，实时性没有那么强。

　　

　　以上是引入版本分支流程：

　　对于版本和代码分支的问题，我觉得这应该是有意义的，但是，最好不要维护太多的版本，版本应该是短暂的，等新的版本发布时，老的版本就应该删除掉了。

总结

　　总之，GitFlow大而全，但是很重；中心式协同流简单但扩展性不好；功能分支和GitHub协同流轻量灵活(无须关注环境和多版本)，适应性强大(既能适应快速开发和迭代，也适应CI/CD)，个人倾向使用这功能分支协同工作流。当然没有一招鲜吃遍天的银弹，具体选择什么协作流程还是要具体分析，比如GitFlow的这种流程，可以考虑把Release分支裁剪掉，保证轻量化的同时，也能满足实际流程的需要；中心式的流程增加版本分支，也能很好的管理产品的版本代码。

　　当我们把精力放在软件架构和开发流程优化上，我们的git协同流会变得更加简单，所以与其熟练玩弄git协同流，不如放心思放在架构和开发流程的优化上，这才有事倍功半的效果。最后附上对比图，供你选择和参考，如果你们的团队有更好的用法，请多赐教。