原文链接：https://www.atlassian.com/git/tutorials/comparing-workflows
集中式工作流
一般来说，Git 的好处在于分布式的工作流，但是也可以使用传统的工作流方式（如果整个开发团队从SVN转Git，大家都不太熟悉分布式工作流的时候，可以考虑前期先用这种方式熟悉哦！）
讲点理论
Git的好处( vs SVN)
- 每个人都有一份完整的库的代码，这样每个人都可以独立开发互不影响，随时提交，方便的时候再和其他人的合并
- 有强大的分支和合并机制，库之间合并起来非常方便而且最大限度容错
怎么做
- 和SVN一样，大家都把代码提交到同一个库的同一个分支上（比如master或者develop），不需要其他分支
- 克隆这个分支到本地，在本地分支上进行开发（可以在本地进行独立的提交等）
- push到线上
处理冲突
- 如果提交的本地分支和线上分支的提交记录有不同的地方，Git会拒绝接收提交
- 提交之前应该先拉一把，然后Git会保证你的所有本地变更，是基于最新的线上代码之上的(rebasing)。这样做的结果，是形成一个线性的历史记录，和SVN的工作流一样。
- 如果线上的最新版本代码和本地提交代码有直接冲突，Git会让你处理冲突
来点实践
额...暂缺
下一步
从上面的小栗子可以看到，用Git其实是可以完全赋值SVN的使用方法的，但是，这样做并没有充分利用Git的分布式特性。
如果团队已经适应了集中式的工作流，但是想简化多人开发的合作的过程，可以探索下Feature Branch Workflow —— 之前把每次提交都直接集成到主分支上，用这种模式，可以在把新特性提交到主分支之前，对要提交的代码，发起一轮讨论 —— 适合用来做code review哦！
Feature Branch Workflow
熟悉了集中式之后，可以为流程中添加feature branches，这样可以促进合作降低开发者间的交流成本。
这种方式的核心在于，所有功能开发，不能在主分支进行，而应该在独立分支进行。
这种方式，让多人合作开发一个功能而不影响主代码更简单。同时也意味着，主分支永远不会包含未完成的代码，这一点对持续集环境成非常重要。
这种方式，可以使用pull request方案来为提交的分支添加评论 - 让另一个开发者有机会对你开发的东东进行code review，也可以通过pull request的方式邀请别人帮你解决问题。pull request让团队交流非常容易。
讲点理论
怎么做
这种方案依然使用一个中央仓库，master分支依然是正式分支。但是开发者不能直接提交到这个分支，而是每次做一个新功能的时候，创建一个新分支。这个功能分支，应该有一个能够自解释的名字。
Pull Request
开发完一个功能以后，别立刻merge到master上，而是应该新建一个pull request，让其他开发者看看，能不能merge到master上。这样就能保证，在你写的代码合并到主分支之前，其他开发者有机会review到这些change。
除此之外，还能用在代码讨论上，也就是说在开发流程的前期也可以应用。
一旦一个pr被接受，那么发布一个功能就和集中式的差不多了。首先，需要确保本地代码是最新的，然后把你的分支merge到主分支就好了。
来点实践
额......暂缺
下一步
Feature Branch Workflow是一种非常自由的开发模式，但是它太自由了。大型团队开发的时候，有的时候需要需要给分支配置多种不同的角色，这个时候，Gitflow workflow就登场了！
Gitflow Workflow
Forking Workflow
