在集中式版本控制系統(tǒng)中，每個開發(fā)者就像是連接在集線器上的節(jié)點，彼此的工作方式大體相像。而在 Git 中，每個開發(fā)者同時扮演著節(jié)點和集線器的角色。也就是說，每個開發(fā)者既可以將自己的代碼貢獻到其他的倉庫中，同時也能維護自己的公開倉庫，讓其他人可以在其基礎上工作并貢獻代碼。

由此，Git 的分布式協(xié)作可以為你的項目和團隊，衍生出種種不同的工作流程，接下來會介紹幾種常見Git工作流程。

你可以選擇使用其中的某一種，或者將它們的特性混合搭配使用。

2、集中式工作流

Git為了便于客戶機之間的協(xié)同工作，Git版本控制系統(tǒng)一般會設置一個中央版本庫服務器，目的是讓所有客戶機都從該主機更新版本，提交最新版本，該工作模式下的客戶機地位都平等。

集中式工作流像SVN一樣，以中央倉庫作為項目所有修改的單點實體，所有修改都提交到 Master分支上。這種方式與 SVN 的主要區(qū)別就是開發(fā)人員有本地庫，但是Git 很多特性并沒有用到。

如下圖：

上圖說明：

一個遠程倉庫。
一個主分支master。
團隊每個成員都有一個本地倉庫，在本地倉庫中進行代碼的編輯、暫存和提交工作。

集中式工作流總結：

適用人群：小型開發(fā)小團隊，習慣使用SVN工具的小團隊。

工作方式：

團隊組長創(chuàng)建遠程倉庫，創(chuàng)建一個master分支，組員可讀可寫。
每個開發(fā)人員都git clone遠程倉庫到本地倉庫，在master分支上開發(fā)。
每次開發(fā)都要git pull更新遠程倉庫的master分支版本到本地。
每次開發(fā)完成就git commit到本地倉庫，接著git push到遠程倉庫。

缺點：

忘了git push，一直會提交到本地倉庫，沒有推送到遠程倉庫。
忘了git pull，導致本地倉庫與中央倉庫不一致，發(fā)生文件沖突。
大量操作git pull，導致增加Git分支合并次數，增加了Git變基次數，降低了Git的性能。

3、分支工作流

功能分支工作流在集中式工作流的基礎上，為各個新功能分配一個專門的分支來開發(fā)，即在master主分支外在創(chuàng)建一個分支，程序員開發(fā)的新功能全部push到此分支上，等到功能成熟的時候，再把此分支合并到主分支master上。

如下圖：

分支工作流總結：

適用人群：小型開發(fā)團隊，熟悉Git分支的團隊。

工作方式：

團隊組長創(chuàng)建遠程倉庫，創(chuàng)建一個master分支，組員可讀不可寫。
每個開發(fā)人員都git clone遠程倉庫到本地倉庫。
每個開發(fā)人員創(chuàng)建自己的feature分支，在feature分支上開發(fā)。（記住，feature分支是基于master分支）
每個開發(fā)人員每次開發(fā)完成就git commit到本地倉庫中自己的feature分支，接著git push到遠程倉庫。
通過pull request提醒團隊組長，瀏覽組員提交feature分支。
組長把feature分支拉下來，然后合并到自己本地倉庫的master分支上測試。
組長測試feature分支通過之后，由組長負責把feature分支合并到遠程倉庫的master分支上。
組長在遠程倉庫把合并過的feature分支刪除。
組員在本地倉庫把合并過的feature分支刪除。
組員將本地倉庫分支切換為master分支，然后git pull將本地倉庫的master分支更新到遠程倉庫的master分支版本。

缺點：

增加團隊組長的工作量。
增加團隊組員提交步驟。

說明：Pull Request作用是可以讓其他組員或組長可以查看你的代碼，并可以提出代碼修改意見或者討論。

4、GitFlow 工作流(最流行)

Gitflow工作流沒有用超出上面功能分支工作流的概念和命令，而是為不同的分支，分配一個很明確的角色，并定義分支之間如何交互，和什么時候進行交互。

除了有master主分支（用于存儲正式發(fā)布的歷史版本）外，還有一個作為功能集成分支的develop分支。
當初始化完成后，某個程序員想要開發(fā)一個功能，并不是直接從master分支上拉出新分支，而是使用develop分支作為父分支來拉出新分支。
當新功能完成后，再合并回父分支，新功能的提交并不與master分支直接交互。
一旦develop分支上有了做一次發(fā)布（或者說快到了既定的發(fā)布日）的足夠功能，就從develop分支上checkout一個發(fā)布分支。
新建的發(fā)布分支用于開始發(fā)布循環(huán)，所以從這個時間點開始之后新的功能，不能再加到這個分支上，該分支只應該做Bug修復、文檔生成和其它面向發(fā)布任務。
一旦對外發(fā)布的工作都完成了，發(fā)布分支合并到master分支，并分配一個版本號打好Tag。
另外，這些從新建發(fā)布分支以來的做的修改，要合并回develop分支上。
維護分支或說是熱修復（hotfix）分支用于，快速給產品發(fā)布版本（production releases）打補丁，這是唯一可以直接從master分支fork出來的分支。
修復完成，修改應該馬上合并回master分支和develop分支（當前的發(fā)布分支），master分支應該用新的版本號打好Tag。
為Bug修復使用專門分支，讓團隊可以快速處理掉問題，而不用打斷其它工作或是等待下一個發(fā)布循環(huán)。
你可以把維護分支想成是一個直接在master分支上處理的臨時發(fā)布。

總結就是：Gitflow 工作流通過為功能開發(fā)、發(fā)布準備和維護設立了獨立的分支，讓發(fā)布迭代過程更流暢，充分的利用了分支的特點。嚴格的分支模型也為大型項目提供了一些非常必要的結構。

下圖是完整的Gitflow 工作流開發(fā)方式圖，但實際開發(fā)工作環(huán)境可能會精簡：

Gitflow工作流總結：

適用人群：任何開發(fā)團隊，熟悉Git分支的團隊。

工作方式：

項目維護者創(chuàng)建項目維護者的遠程倉庫，創(chuàng)建master分支與develop分支，貢獻者可讀不可寫。
每個貢獻者git clone遠程倉庫中的develop分支到本地倉庫。（記住，develop分支相當于master的分支，包括功能開發(fā)，修改，測試。master分支相當于最終分支）
每個貢獻者在本地倉庫創(chuàng)建自己的feature分支，在feature分支上開發(fā)。
在feature分支又可以創(chuàng)建多個feature分支，繼續(xù)開發(fā)項目。
每個貢獻者每次開發(fā)完成就git commit到本地倉庫中自己的feature分支，接著git push到遠程倉庫。
通過pull request提醒項目維護者，瀏覽貢獻者提交feature分支。
項目維護者把feature分支拉下來，然后合并到自己本地倉庫的develop分支上測試。
組長測試feature分支通過之后，由組長負責把feature分支合并到遠程倉庫的develop分支上。
項目維護者會release分支上git tag打上版本號。
項目維護者可以從develop分支創(chuàng)建release分支，接著把release分支合并到master分支上，同時master分支同步到develop分支。
項目維護者在遠程倉庫把合并過的feature分支刪除。
每個貢獻者在本地倉庫把合并過的feature分支刪除。
每個貢獻者將本地倉庫分支切換為develop分支，然后git pull將本地倉庫的master分支更新到遠程倉庫的develop分支版本。

說明：Gitflow工作流是Vincent Driessen工程師提出的多分支工作流。

5、Forking 工作流(偶爾使用)

分叉(Forking)工作流也可以叫做分布式工作流，是在 GitFlow工作流的基礎上的衍生，充分利用了Git在分支和克隆上的優(yōu)勢，再加上pull request 的功能，以達到代碼審核的目的。既可以管理大團隊的開發(fā)者（developer）的提交，也可以接受不信任貢獻者（contributor）的提交。

這種工作流使得每個開發(fā)者都有一個服務端倉庫（此倉庫只有自己可以push推送，但是所有人都可以pull拉取修改），每個程序員都push代碼到自己的服務端倉庫，但不能push到正式倉庫，只有項目維護者才能push到正式倉庫，這樣項目維護者可以接受任何開發(fā)者的提交，但無需給他正式代碼庫的寫權限。

這種工作流適合開源社區(qū)的開源項目，大家統(tǒng)一對項目做貢獻，但是有一個人或一個團隊作為開發(fā)者來管理項目，所有的貢獻者的代碼由開發(fā)者審核，其功能完善之后再由開發(fā)者push到正式倉庫中。

總結：

分叉(Forking)工作流更適合安全可靠地管理大團隊的開發(fā)者，而且能接受不信任貢獻者的提交。
在實際工作中，如果偶爾有需要團隊外的成員幫我們解決問題時，可能會用到。
這種工作流程并不常用，只有當項目極為龐雜，或者需要多級別管理時，才會體現出優(yōu)勢。利用這種方式，項目總負責人（即主管）可以把大量分散的集成工作，委托給不同的小組負責人分別處理，然后在不同時刻將大塊的代碼子集統(tǒng)籌起來，用于之后的整合。

圖示如下：