Git
章節 ▾ 第二版

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

現在您已經設定了遠端 Git 儲存庫作為所有開發人員分享程式碼的中心點，並且熟悉了本機工作流程中的基本 Git 指令，接下來您將了解如何運用 Git 提供的一些分散式工作流程。

在本章中，您將看到如何在分散式環境中以貢獻者和整合者的身份使用 Git。也就是說，您將學習如何成功地為專案貢獻程式碼，並盡可能讓您和專案維護者都方便，以及如何成功地維護一個由許多開發人員貢獻的專案。

分散式工作流程

與集中式版本控制系統 (CVCS) 相比，Git 的分散式特性讓您在開發人員如何協作處理專案方面更具彈性。在集中式系統中，每個開發人員都是一個節點，或多或少與中心樞紐平等地工作。然而，在 Git 中，每個開發人員都可能既是節點又是樞紐；也就是說，每個開發人員都可以為其他儲存庫貢獻程式碼，並維護一個公共儲存庫，其他人可以在此基礎上進行工作並為其貢獻。這為您的專案和/或您的團隊提供了廣泛的工作流程可能性，因此我們將介紹一些利用這種彈性的常見範例。我們將探討每種設計的優點和可能的缺點；您可以選擇使用單一設計，也可以混合搭配每種設計的功能。

集中式工作流程

在集中式系統中，通常有一個單一的協作模型，即集中式工作流程。一個中心樞紐或儲存庫可以接受程式碼，並且每個人都與其同步他們的工作。許多開發人員是節點，即該樞紐的使用者，並與該集中位置同步。

Centralized workflow
圖 53. 集中式工作流程

這表示如果兩位開發者從 Hub 複製專案並都進行了變更，第一位將變更推回的開發者可以順利完成。第二位開發者必須先合併第一位開發者的工作，才能推送變更，以避免覆蓋第一位開發者的變更。這個概念在 Git 中與在 Subversion (或任何 CVCS) 中一樣成立，並且這個模型在 Git 中運作良好。

如果您的公司或團隊已經習慣集中式工作流程，您可以輕鬆地繼續在 Git 中使用該工作流程。只需設定一個單一的儲存庫，並給予您團隊中的每個人推送權限即可；Git 不會讓使用者互相覆蓋彼此的變更。

假設 John 和 Jessica 同時開始工作。John 完成了他的變更並將其推送到伺服器。然後 Jessica 嘗試推送她的變更，但伺服器拒絕了。她被告知她嘗試推送非快速轉送變更，並且必須先提取 (fetch) 和合併 (merge) 才能推送。這種工作流程對很多人來說很有吸引力，因為它是一種許多人熟悉且習慣的範例。

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

整合管理者工作流程

由於 Git 允許您擁有複數個遠端儲存庫，因此可以採用一種工作流程，讓每位開發者都擁有對自己公開儲存庫的寫入權限，以及對其他所有人儲存庫的讀取權限。這種情境通常包含一個代表「官方」專案的標準儲存庫。為了對該專案做出貢獻，您可以建立自己公開的專案複本，並將您的變更推送到其中。然後，您可以向主專案的維護者發送請求，要求他們拉取您的變更。維護者可以將您的儲存庫添加為遠端，在本機測試您的變更，將它們合併到他們的分支中，然後推回他們的儲存庫。這個流程如下 (請參閱 整合管理者工作流程)：

  1. 專案維護者將內容推送到他們的公開儲存庫。

  2. 貢獻者複製該儲存庫並進行變更。

  3. 貢獻者將內容推送到他們自己的公開副本。

  4. 貢獻者向維護者發送電子郵件，請求他們拉取變更。

  5. 維護者將貢獻者的儲存庫添加為遠端，並在本機進行合併。

  6. 維護者將合併後的變更推送到主儲存庫。

Integration-manager workflow
圖 54. 整合管理者工作流程

這是在 GitHub 或 GitLab 等基於 Hub 的工具中非常常見的工作流程，在這些工具中，您可以輕鬆地 Fork 一個專案，並將您的變更推送到您的 Fork 中，以便所有人都能看到。這種方法的主要優勢之一是您可以繼續工作，並且主儲存庫的維護者可以隨時拉取您的變更。貢獻者不必等待專案納入他們的變更，每個參與者都可以按照自己的步調工作。

獨裁者和副官工作流程

這是多儲存庫工作流程的一種變體。它通常由擁有數百位協作者的大型專案使用；一個著名的例子是 Linux 核心。各種整合管理者負責儲存庫的某些部分；他們被稱為 *副官*。所有副官都有一位稱為仁慈獨裁者的整合管理者。仁慈獨裁者從他們的目錄推送到一個參考儲存庫，所有協作者都需要從該儲存庫拉取內容。這個流程如下 (請參閱 仁慈獨裁者工作流程)：

  1. 一般開發人員在他們的主題分支上工作，並將他們的工作 Rebase 到 master 的頂部。master 分支是獨裁者推送到的參考儲存庫的分支。

  2. 副官將開發人員的主題分支合併到他們的 master 分支中。

  3. 獨裁者將副官的 master 分支合併到獨裁者的 master 分支中。

  4. 最後，獨裁者將該 master 分支推送到參考儲存庫，以便其他開發人員可以基於它 Rebase。

Benevolent dictator workflow
圖 55. 仁慈獨裁者工作流程

這種工作流程並不常見，但對於非常大的專案或高度階層化的環境可能很有用。它允許專案領導者 (獨裁者) 委派大部分工作，並在整合之前於多個點收集大量的程式碼子集。

管理原始碼分支的模式

注意

Martin Fowler 撰寫了一份指南「管理原始碼分支的模式」。本指南涵蓋了所有常見的 Git 工作流程，並說明如何/何時使用它們。還有一個章節比較了高和低整合頻率。

https://martinfowler.dev.org.tw/articles/branching-patterns.html

工作流程總結

這些是使用像 Git 這樣的分散式系統可能用到的一些常用工作流程，但您可以看到可以進行許多變化，以適應您特定的現實世界工作流程。既然您 (希望) 可以確定哪個工作流程組合可能適合您，我們將介紹一些更具體的範例，說明如何完成構成不同流程的主要角色。在下一節中，您將了解一些為專案做出貢獻的常見模式。

scroll-to-top