原文鏈接：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
