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

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

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

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

假設 John 和 Jessica 同時開始工作。John 完成了他的更改並將其推送到伺服器。然後 Jessica 嘗試推送她的更改，但伺服器拒絕了。她被告知她正在嘗試推送非快進更改，並且除非她拉取併合並，否則無法完成。這種工作流對很多人很有吸引力，因為它是一個許多人都熟悉並感到舒適的正規化。

這也不僅限於小型團隊。藉助 Git 的分支模型，數百名開發者可以透過數十個分支同時成功地在一個專案上工作。

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

這是使用像 GitHub 或 GitLab 這樣基於樞紐的工具時非常常見的工作流，在這種工具中，你可以輕鬆地派生一個專案，並將你的更改推送到你的派生中供所有人檢視。這種方法的主要優點之一是你可以繼續工作，並且主倉庫的維護者可以隨時拉取你的更改。貢獻者不必等待專案合併他們的更改——各方都可以按照自己的節奏工作。

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

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

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