5.1 Git 分散式 - 分散式工作流

在集中式系統中，通常只有一種協作模式——集中式工作流。一箇中心樞紐，或稱倉庫，可以接受程式碼，每個人都將其工作與之同步。許多開發人員是節點——該樞紐的消費者——並與該集中位置同步。

這意味著，如果兩個開發人員從樞紐克隆並都進行了更改，第一個將更改推回的人可以毫無問題地完成。第二個開發人員在推送更改之前必須合併第一個開發人員的工作，以免覆蓋第一個開發人員的更改。這個概念在 Git 中與在 Subversion（或任何 CVCS）中一樣真實，而且這種模式在 Git 中也能完美執行。

如果您已經習慣了公司或團隊中的集中式工作流，那麼您可以使用 Git 輕鬆地繼續使用該工作流。只需設定一個倉庫，並給予團隊中的每個人推送許可權；Git 不會讓使用者覆蓋彼此。

假設 John 和 Jessica 同時開始工作。John 完成了他的更改並將其推送到伺服器。然後 Jessica 嘗試推送她的更改，但伺服器拒絕了。她被告知她正在嘗試推送非快進式更改，並且在獲取和合並之前無法這樣做。這種工作流對許多人來說很有吸引力，因為這是許多人熟悉和習慣的模式。

這也不僅限於小型團隊。藉助 Git 的分支模型，數百名開發人員可以同時在數十個分支上成功地處理單個專案。

由於 Git 允許您擁有多個遠端倉庫，因此可以採用一種工作流，其中每個開發人員都對其自己的公共倉庫擁有寫訪問許可權，並對其餘所有人的倉庫擁有讀訪問許可權。這種情況通常包括一個代表“官方”專案的規範倉庫。要為此專案做出貢獻，您可以建立專案自己的公共克隆，並將您的更改推送到其中。然後，您可以向主專案維護者傳送請求，要求他們拉取您的更改。維護者隨後可以將您的倉庫新增為遠端倉庫，在本地測試您的更改，將其合併到他們的分支中，然後推回到他們的倉庫。該過程如下（請參閱 整合經理工作流）

這是像 GitHub 或 GitLab 這樣的基於 Hub 的工具中非常常見的工作流，在那裡可以輕鬆地 Fork 一個專案並將您的更改推送到您的 Fork 中供大家檢視。這種方法的主要優點之一是您可以繼續工作，而主倉庫的維護者可以隨時拉取您的更改。貢獻者不必等待專案合併他們的更改——雙方都可以按照自己的節奏工作。

這是多倉庫工作流的一個變體。它通常由擁有數百名協作者的龐大專案使用；一個著名的例子是 Linux 核心。各種整合經理負責倉庫的特定部分；他們被稱為副手。所有副手都有一個被稱為仁慈的獨裁者的整合經理。仁慈的獨裁者從其目錄推送到一個參考倉庫，所有協作者都需要從中拉取。該過程如下（請參閱 仁慈的獨裁者工作流）

這種工作流並不常見，但在非常大的專案或高度分層的環境中可能很有用。它允許專案負責人（獨裁者）委派大量工作，並在多個點收集大塊程式碼，然後再將其整合。

這些是像 Git 這樣的分散式系統可能支援的一些常用工作流，但您可以看到，可能存在許多變體來適應您特定的實際工作流。現在您（希望）可以確定哪種工作流組合可能適合您，我們將介紹一些更具體的示例，說明如何完成構成不同流程的主要角色。在下一節中，您將學習一些貢獻專案的常見模式。