前言
git作为当前普及率很高的代码版本管理工具，在工作和个人使用中有多种工作流方式，不同的工作流也对应着不同的使用场景，因此笔者在这里总结一下使用git以来遇到的多种使用方式。
分布式版本控制系统
开始之前，我觉得我们要对git的基本概念有所了解，git在本质上是一种分布式版本控制系统，而对应的svn则是集中式的版本控制系统。如下图所示：集中式的svn除了对于SVN服务器上部署代码仓库之外，其他所有协同工作的伙伴都是一个对应的文件副本，没有仓库的全部信息，即伙伴们同步信息只能通过SVN的中央仓库，而一旦中央仓库除出了问题，就只能等待修复完成后才能提交和同步代码。
与之对应的分布式版本控制系统git则不然，我们每个伙伴执行了git clone操作的本地仓库都是一个版本库，相对来说去除了中央仓库这个概念，而对应我们搭建的远程仓库一旦出了问题，我们依旧可以在本地进行维护和对文件版本的维护，甚至我们可以这样做，两个伙伴如果是在同一网段下，还可以将对方的仓库当做中央仓库去同步数据。
正文
接下来就来说一下关于在使用git时遇到的多种工作流方式。分别是类似于SVN的集中式工作流、git flow工作流、fork pull request工作流。
集中式
集中式如下图所示，有点类似于SVN操作方式的工作流，所有的伙伴都只在master分支上维护代码，适用于团队和产品都比较小的情况，或者是个人项目，比如自己的demo项目等，可以以较低的学习成本完成对git的使用，但无法利用其它特性优化项目代码管理。 集中式经常使用到的命令：
git clone
git pull origin
git push origin
git flow
git flow方式是我在工作中见过大多数团队在使用的git工作流，适合，如下图所示，git flow支持在以远程中央仓库origin master分支为基准的基础之下可以并行有多个分支，如我们的灰度分支（release）、仿真环境分支（test）、每个版本特性对应并行开发的feature分支。每个人可以操作不同的分支，很好的利用了git的分支特性，实现了不同环境的隔离，而且可以有筛选的将版本对应及测试通过的代码合并至mater主分支，在git flow工作流中，我们经常用到：
git clone
git push
git pull
git merge
git checkout
git fork pull request
基于fork仓库的git工作流，是我认为最为合理且安全实用的工作流方式，只是相对git flow来说操作比较麻烦。如下图所示，我们在git fork工作流中，基于中央远程仓库进行fork，fork出个人远程仓库并且会复制完整中央远程仓库，建立起关联关系，接着我们队自己的远程仓库进行clone到本地，进行持续的迭代开发。对于同步至中央仓库来说，相对git flow多了一次merge的操作，即我们每次推代码变动，都会将变化推送至自己的个人远程仓库，接着，在gitlab或github等网页上发起一次合并请求：从自己的个人远程仓库feature分支合并至中央远程仓库的feature分支，最终手动接收此次merge request完成代码合并。相对于git flow多出了一次在网页上操作的手动merge。
git fork式的工作流也常见于各种开源项目中，比如github中大型开源项目的贡献代码方式，并且在工作中使用git fork式的操作，也能够增加对于git操作的容错性，比如我们push代码到了错误的分支，这时只是我们自己的个人远程仓库受到了影响，公用的远程仓库没有受到影响，我们可以在自己仓库中进行错误修复等操作，时刻保持中央远程的正确性。在git flow工作流中，我们经常用到：
fork
git clone
git add upstream XX.git //添加中央远程仓库为upstream的命名
git fetch upstream //获取中央远程仓库最近的更新
git rebase upstream/feature1 //使用rebase变基同步合并中央远程仓库对应feature1分支代码
git push origin/feature1 //推送代码变动至个人远程仓库
总结
总结一下，这篇针对当前遇到的3中主要的git工作流进行了分析，其中每种都有自己的实用场景和优劣势：
- 集中式：适合小团队简单产品迭代；
- git flow：适合较大团队，复杂场景及较多环境的产品迭代，合理利用了git 分支优势；
- git fork：适合较大团队，开源项目或公司中央仓库要求高质量，操作相对复杂。
总之，就是如果在工作中，如果我们对自己的操作足够自信及犯错后可短时间内完美解决，完全可以使用git flow，在利用分支特性的同时也有较高的git操作效率；否则git fork是一个不错的选择。
