之前開的坑來補。
如何利用 Git 的團隊協(xié)作是個問題，處理不好會讓工作事倍功半。
我在學習的過程中了解到了4種 Git 團隊協(xié)作的方式。
1.中心化工作流
2.基于功能分支的工作流
3.Gitflow 工作流
4.Fork 工作流
中心化工作流
中心化工作流將中央倉庫作為項目中所有修改的唯一入口。這種工作流不需要 master 之外的其他分支。
如何工作
開發(fā)者將中央倉庫 clone 到本地后開始工作。在他們的本地倉庫中，可以修改文件和提交更改，但是，所有新的提交都保存在本地，和中央倉庫完全隔離。開發(fā)者可以將 upstream 的同步推遲到他們方便的時候去做。
管理沖突
在開發(fā)者發(fā)布功能之前，需要先 fetch 更新到最新到中央倉庫，在它們之上 rebase 自己到更改。 這樣的優(yōu)點是可以留下完美的線性歷史。
這套協(xié)作方式對于 SVN 的使用團隊來說很棒，但是沒有用到 Git 分布式的優(yōu)點。
Feature 分支工作流
當你熟練使用 Git 之后，在你的開發(fā)流程中添加功能分支是一個非常能促進團隊協(xié)作的方式。
這種工作流的好處是，多個開發(fā)者專注自己的功能而不會打擾中央倉庫。還能保證 master 分支永遠不會包含質(zhì)量有問題的代碼，給持續(xù)集成環(huán)境帶來了很大好處。
封裝功能的開發(fā)方式使得 Pull Request 的使用更加方便。它可以在開發(fā)者在功能并入項目之前一起參與討論，提出問題，或者尋求建議。
如何工作
Feature 分支工作流同樣使用中央倉庫的概念，master 分支代表官方的項目歷史。開發(fā)者每次進行新的工作時，創(chuàng)建一個新的分支，該分支名稱應為描述功能或者針對某一 issue 。
feature 分支也應該被推送到中央倉庫。這使得你和其他開發(fā)者共享這個功能，而又不會改變官方代碼。
Pull Request 是分支工作流里非常便利的工具，有人如果完成了一個功能，他們不會立刻并入master。他們將 feature 分支推送到中央倉庫發(fā)布一個 Pull Request 。這樣可以在并入主代碼庫之前讓所有其他開發(fā)者審查代碼。Pull Request 也是一個討論板塊，任何人遇到問題需要幫助時可以發(fā)起一個 Pull Request 讓其他開發(fā)者看到。
GitFlow 工作流
GitFlow工作流相比功能分支工作流沒有增加新的概念，它給不同的分支制定的不同的功能，嚴格定義了它們應該怎樣以及何時進行交流。
開發(fā)分支
對于一個開發(fā)人員來說，開發(fā)分支是打交道最多的分支。每增加一個功能，就在開發(fā)分支的基礎上新建一個功能分支，每當功能開發(fā)完成時，它會杯合并會開發(fā)分支。功能分支 永遠不應該跟 master 交互。
發(fā)布分支
一旦 開發(fā)分支的新功能開發(fā)到一定程度（deadline 或者 其他原因），你可以從 開發(fā)分支 fork 出來一個分支發(fā)布。這個分支的創(chuàng)建開始了下一個發(fā)布周期。只有和發(fā)布有關的工作應該在詞分支上進行。
發(fā)布完成后，發(fā)布分支將合并進 master，并打上版本號標簽。另外也應該合并回 develop ，后者可能在發(fā)布啟動后又有了新的改動。
通常使用一個專門的分支來準備確保一個團隊修復當前發(fā)布的功能，其他團隊可以開發(fā)下一個發(fā)布的功能。
維護分支
維護分支 （hotfix）用來緊急給產(chǎn)品的發(fā)布打上布丁，這是唯一可以從 master 上 fork 的分支。修復完成后，它們應該被并入 master 和 develop 分支。
實際的工作流程，則需要根據(jù)上面規(guī)則和實際情況進行詳細的規(guī)劃。
Fork 工作流
Fork 工作流不同與其他幾個工作流。這個工作流可以讓每個開發(fā)者都擁有一個服務端倉庫。也就是說每個貢獻者都有兩個Git倉庫，一個開放的服務端倉庫，和私有的倉庫。
Fork 工作流的主要有點在于代碼可以輕易的整合進項目，而不需要每個人都推送到單一的中央倉庫。開發(fā)者推送他們自己的服務端倉庫，只有項目管理者可以推送到官方倉庫。這使得管理者可以結束任何開發(fā)者的提交，卻不需要給他們中央倉庫的權限。
在工作項目中，本源規(guī)定了一套 Git Flow 工作流，后來因為開發(fā)者只有我一個人（partner在比較閑的時候時不時會來貢獻幾個功能），并且沒有 中央代碼庫 的權限。所以后來就逐漸轉變成了 Fork 工作流。
相比前三個工作流，F(xiàn)ork 工作流使用起來更簡單，且最安全。因為貢獻代碼的人并不干擾中央倉庫，只通過 Pull Request 來和中央代碼庫進行交互，最適用的場景就是開源倉庫，和松散型的開發(fā)團隊使用。
以上就是在和 Partner 尋找有效的工作方式時，學習到的 Git 團隊工作流程。以后如果遇到其他新奇的工作流程會再補充更新。
