你現在擁有了乙個遠端 git 版本庫，能為所有開發者共享**提供服務，在乙個本地工作流程下，你也已經熟悉了基本 git 命令。你現在可以學習如何利用 git 提供的一些分布式工作流程了。
這一章中，你將會學習如何作為貢獻者或整合者，在乙個分布式協作的環境中使用 git。 你會學習為乙個專案成功地貢獻**，並接觸一些最佳實踐方式，讓你和專案的維護者能輕鬆地完成這個過程。另外，你也會學到如何管理有很多開發者提交貢獻的專案。
與傳統的集中式版本控制系統（cvcs）相反，git 的分布式特性使得開發者間的協作變得更加靈活多樣。 在集中式系統中，每個開發者就像是連線在集線器上的節點，彼此的工作方式大體相像。 而在 git 中，每個開發者同時扮演著節點和集線器的角色——也就是說， 每個開發者既可以將自己的**貢獻到其他的倉庫中，同時也能維護自己的公開倉庫， 讓其他人可以在其基礎上工作並貢獻**。 由此，git 的分布式協作可以為你的專案和團隊衍生出種種不同的工作流程， 接下來的章節會介紹幾種利用了 git 的這種靈活性的常見應用方式。 我們將討論每種方式的優點以及可能的缺點；你可以選擇使用其中的某一種，或者將它們的特性混合搭配使用。
集中式系統中通常使用的是單點協作模型——集中式工作流。 乙個中心集線器，或者說倉庫，可以接受**，所有人將自己的工作與之同步。 若干個開發者則作為節點，即中心倉庫的消費者與中心倉庫同步。
figure 54. 集中式工作流。
這意味著如果兩個開發者從中心倉庫轉殖**下來，同時作了一些修改，那麼只有第乙個開發者可以順利地把資料推送回共享伺服器。 第二個開發者在推送修改之前，必須先將第乙個人的工作合併進來，這樣才不會覆蓋第乙個人的修改。 這和 subversion （或任何 cvcs）中的概念一樣，而且這個模式也可以很好地運用到 git 中。
如果在公司或者團隊中，你已經習慣了使用這種集中式工作流程，完全可以繼續採用這種簡單的模式。 只需要搭建好乙個中心倉庫，並給開發團隊中的每個人推送資料的許可權，就可以開展工作了。git 不會讓使用者覆蓋彼此的修改。
例如 john 和 jessica 同時開始工作。 john 完成了他的修改並推送到伺服器。 接著 jessica 嘗試提交她自己的修改，卻遭到伺服器拒絕。 她被告知她的修改正通過非快進式（non-fast-forward）的方式推送，只有將資料抓取下來並且合併後方能推送。 這種模式的工作流程的使用非常廣泛，因為大多數人對其很熟悉也很習慣。
當然這並不侷限於小團隊。 利用 git 的分支模型，通過同時在多個分支上工作的方式，即使是上百人的開發團隊也可以很好地在單個專案上協作。
git 允許多個遠端倉庫存在，使得這樣一種工作流成為可能：每個開發者擁有自己倉庫的寫許可權和其他所有人倉庫的讀許可權。 這種情形下通常會有個代表「官方」專案的權威的倉庫。 要為這個專案做貢獻，你需要從該專案轉殖出乙個自己的公開倉庫，然後將自己的修改推送上去。 接著你可以請求官方倉庫的維護者拉取更新合併到主專案。 維護者可以將你的倉庫作為遠端倉庫新增進來，在本地測試你的變更，將其合併入他們的分支並推送回官方倉庫。 這一流程的工作方式如下所示（見 整合管理者工作流。）：
專案維護者推送到主倉庫。
貢獻者轉殖此倉庫，做出修改。
貢獻者將資料推送到自己的公開倉庫。
貢獻者給維護者傳送郵件，請求拉取自己的更新。
維護者在自己本地的倉庫中，將貢獻者的倉庫加為遠端倉庫並合併修改。
維護者將合併後的修改推送到主倉庫。
figure 55. 整合管理者工作流。
這是 github 和 gitlab 等集線器式（hub-based）工具最常用的工作流程。人們可以容易地將某個專案派生成為自己的公開倉庫，向這個倉庫推送自己的修改，並為每個人所見。 這麼做最主要的優點之一是你可以持續地工作，而主倉庫的維護者可以隨時拉取你的修改。 貢獻者不必等待維護者處理完提交的更新——每一方都可以按照自己的節奏工作。
這其實是多倉庫工作流程的變種。 一般擁有數百位協作開發者的超大型專案才會用到這樣的工作方式，例如著名的 linux 核心專案。 被稱為副主管（lieutenant）的各個整合管理者分別負責整合專案中的特定部分。 所有這些副主管頭上還有一位稱為主管（dictator）的總整合管理者負責統籌。 主管維護的倉庫作為參考倉庫，為所有協作者提供他們需要拉取的專案**。 整個流程看起來是這樣的（見 主管與副主管工作流。 ）：
普通開發者在自己的主題分支上工作，並根據master分支進行變基。 這裡是主管推送的參考倉庫的master分支。
副主管將普通開發者的主題分支合併到自己的master分支中。
主管將所有副主管的master分支併入自己的master分支中。
最後，主管將整合後的master分支推送到參考倉庫中，以便所有其他開發者以此為基礎進行變基。
figure 56. 主管與副主管工作流。
這種工作流程並不常用，只有當專案極為龐雜，或者需要多級別管理時，才會體現出優勢。 利用這種方式，專案總負責人（即主管）可以把大量分散的整合工作委託給不同的小組負責人分別處理，然後在不同時刻將大塊的**子集統籌起來，用於之後的整合。
上面介紹了在 git 等分布式系統中經常使用的工作流程，但是在實際的開發中，你會遇到許多可能適合你的特定工作流程的變種。 現在你應該已經清楚哪種工作流程組合可能比較適合你了，我們會給出一些如何扮演不同工作流程中主要角色的更具體的例子。 下一節我們將會學習為專案做貢獻的一些常用模式。
原文：
分布式 Git 分布式工作流程
同傳統的集中式版本控制系統 cvcs 不同，開發者之間的協作方式因著 git 的分布式特性而變得更為靈活多樣。在集中式系統上，每個開發者就像是連線在集線器上的節點，彼此的工作方式大體相像。而在 git 網路中，每個開發者同時扮演著節點和集線器的角色，這就是說，每乙個開發者都可以將自己的 貢獻到另外乙...
Git分布式工作流程
git官網給出了三種分布式工作流程 這裡以私有gitserver伺服器上的git test專案為例，簡單說明集中式工作流程。基於分支的開發策略參考git pro 使用分支意味著你可以把你的工作從開發主線上分離開來，以免影響開發主線。使用git開發的過程中，鼓勵使用分支進行迭代開發，分支的建立 刪除 ...
深入理解Git原理 分布式工作流程
同傳統的集中式版本控制系統 cvcs 不同，git 的分布式特性使得開發者間的協作變得更加靈活多樣。在集中式系統中，每個開發者就像是連線在集線器上的節點，彼此的工作方式大體相像。而在 git 中，每個開發者同時扮演著節點和集線器的角色 也就是說，每個開發者既可以將自己的 貢獻到其他的倉庫中，同時也能...