[toc] 你現在擁有了一個遠程 Git 版本庫，能為所有開發者共享代碼提供服務，在一個本地工作流程下，你也已經熟悉了基本 Git 命令。你現在可以學習如何利用 Git 提供的一些分布式工作流程了。 這一章中，你將會學習如何作為貢獻者或整合者，在一個分布式協作的環境中使用 Git。 你會學習為一個項目成功地貢獻代碼，并接觸一些最佳實踐方式，讓你和項目的維護者能輕松地完成這個過程。另外，你也會學到如何管理有很多開發者提交貢獻的項目。 ## 分布式工作流程 同傳統的集中式版本控制系統（CVCS）不同，Git 的分布式特性使得開發者間的協作變得更加靈活多樣。 在集中式系統中，每個開發者就像是連接在集線器上的節點，彼此的工作方式大體相像。 而在 Git 中，每個開發者同時扮演著節點和集線器的角色——也就是說，每個開發者既可以將自己的代碼貢獻到其他的倉庫中，同時也能維護自己的公開倉庫，讓其他人可以在其基礎上工作并貢獻代碼。 由此，Git 的分布式協作可以為你的項目和團隊衍生出種種不同的工作流程，接下來的章節會介紹幾種利用了 Git 的這種靈活性的常見應用方式。 我們將討論每種方式的優點以及可能的缺點；你可以選擇使用其中的某一種，或者將它們的特性混合搭配使用。 ## 集中式工作流 集中式系統中通常使用的是單點協作模型——集中式工作流。 一個中心集線器，或者說倉庫，可以接受代碼，所有人將自己的工作與之同步。 若干個開發者則作為節點——也就是中心倉庫的消費者——并且與其進行同步。  這意味著如果兩個開發者從中心倉庫克隆代碼下來，同時作了一些修改，那么只有第一個開發者可以順利地把數據推送回共享服務器。 第二個開發者在推送修改之前，必須先將第一個人的工作合并進來，這樣才不會覆蓋第一個人的修改。 這和 Subversion （或任何 CVCS）中的概念一樣，而且這個模式也可以很好地運用到 Git 中。 如果在公司或者團隊中，你已經習慣了使用這種集中式工作流程，完全可以繼續采用這種簡單的模式。 只需要搭建好一個中心倉庫，并給開發團隊中的每個人推送數據的權限，就可以開展工作了。Git 不會讓用戶覆蓋彼此的修改。 例如 John 和 Jessica 同時開始工作。 John 完成了他的修改并推送到服務器。 接著 Jessica 嘗試提交她自己的修改，卻遭到服務器拒絕。 她被告知她的修改正通過非快進式（non-fast-forward）的方式推送，只有將數據抓取下來并且合并后方能推送。 這種模式的工作流程的使用非常廣泛，因為大多數人對其很熟悉也很習慣。 當然這并不局限于小團隊。 利用 Git 的分支模型，通過同時在多個分支上工作的方式，即使是上百人的開發團隊也可以很好地在單個項目上協作。 ## 集成管理者工作流 Git 允許多個遠程倉庫存在，使得這樣一種工作流成為可能：每個開發者擁有自己倉庫的寫權限和其他所有人倉庫的讀權限。 這種情形下通常會有個代表‘官方’'項目的權威的倉庫。 要為這個項目做貢獻，你需要從該項目克隆出一個自己的公開倉庫，然后將自己的修改推送上去。 接著你可以請求官方倉庫的維護者拉取更新合并到主項目。 維護者可以將你的倉庫作為遠程倉庫添加進來，在本地測試你的變更，將其合并入他們的分支并推送回官方倉庫。 這一流程的工作方式如下所示（見 集成管理者工作流。）： 1. 項目維護者推送到主倉庫。 2. 貢獻者克隆此倉庫，做出修改。 3. 貢獻者將數據推送到自己的公開倉庫。 4. 貢獻者給維護者發送郵件，請求拉取自己的更新。 5. 維護者在自己本地的倉庫中，將貢獻者的倉庫加為遠程倉庫并合并修改。 6. 維護者將合并后的修改推送到主倉庫。  這是 GitHub 和 GitLab 等集線器式（hub-based）工具最常用的工作流程。人們可以容易地將某個項目派生成為自己的公開倉庫，向這個倉庫推送自己的修改，并為每個人所見。 這么做最主要的優點之一是你可以持續地工作，而主倉庫的維護者可以隨時拉取你的修改。 貢獻者不必等待維護者處理完提交的更新——每一方都可以按照自己節奏工作。 ## 司令官與副官工作流 這其實是多倉庫工作流程的變種。 一般擁有數百位協作開發者的超大型項目才會用到這樣的工作方式，例如著名的 Linux 內核項目。 被稱為副官（lieutenant）的各個集成管理者分別負責集成項目中的特定部分。 所有這些副官頭上還有一位稱為司令官（dictator）的總集成管理者負責統籌。 司令官維護的倉庫作為參考倉庫，為所有協作者提供他們需要拉取的項目代碼。 整個流程看起來是這樣的(見 司令官與副官工作流。): 普通開發者在自己的特性分支上工作，并根據 master 分支進行變基。 這里是司令官的`master`分支。 副官將普通開發者的特性分支合并到自己的 master 分支中。 司令官將所有副官的 master 分支并入自己的 master 分支中。 司令官將集成后的 master 分支推送到參考倉庫中，以便所有其他開發者以此為基礎進行變基。  這種工作流程并不常用，只有當項目極為龐雜，或者需要多級別管理時，才會體現出優勢。 利用這種方式，項目總負責人（即司令官）可以把大量分散的集成工作委托給不同的小組負責人分別處理，然后在不同時刻將大塊的代碼子集統籌起來，用于之后的整合。 工作流程總結 上面介紹了在 Git 等分布式系統中經常使用的工作流程，但是在實際的開發中，你會遇到許多可能適合你的特定工作流程的變種。 現在你應該已經清楚哪種工作流程組合可能比較適合你了，我們會給出一些如何扮演不同工作流程中主要角色的更具體的例子。 下一節我們將會學習為項目做貢獻的一些常用模式。