Git协同工做流介绍

git相关的文章和教程很是多，可是系统介绍和了解工做流的人并很少，在使用过程当中用错或用偏的也很多，这里分享的是，假设你已经入门的状况下，咱们如何去选择适合团队须要的工做流。

git优点

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

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

git经常使用命令

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

　　这里记录本身平时常用的一些命令，并非本文的重点。另外叨叨一下，有些人喜欢在集成的IDE下经过界面方式来进行操做，好比vs code或者eclipse都有傻瓜化的集成，这里推荐使用命令行操做，我以为有以下一些优点:

• 第1、能够和IDE解耦，不用换一个IDE就要去了解对应界面的使用方法；
• 第2、命令行的操做很是快速，固然缺点是你须要记忆一些命令，可是经常使用的命令真心很少；
• 第3、命令行拥有界面没有的体验，好比一个简单的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协同流，不如放心思放在架构和开发流程的优化上，这才有事倍功半的效果。最后附上对比图，供你选择和参考，若是大家的团队有更好的用法，请多赐教。