同傳統的集中式版本控制系統（cvcs）不同，git 的分布式特性使得開發者間的協作變得更加靈活多樣。 在集中式系統中，每個開發者就像是連線在集線器上的節點，彼此的工作方式大體相像。 而在 git 中，每個開發者同時扮演著節點和集線器的角色——也就是說，每個開發者既可以將自己的**貢獻到其他的倉庫中，同時也能維護自己的公開倉庫，讓其他人可以在其基礎上工作並貢獻**。 由此，git 的分布式協作可以為你的專案和團隊衍生出種種不同的工作流程，接下來的章節會介紹幾種利用了 git 的這種靈活性的常見應用方式。 我們將討論每種方式的優點以及可能的缺點；你可以選擇使用其中的某一種，或者將它們的特性混合搭配使用。
集中式系統中通常使用的是單點協作模型——集中式工作流。 乙個中心集線器，或者說倉庫，可以接受**，所有人將自己的工作與之同步。 若干個開發者則作為節點——也就是中心倉庫的消費者——並且與其進行同步。
這意味著如果兩個開發者從中心倉庫轉殖**下來，同時作了一些修改，那麼只有第乙個開發者可以順利地把資料推送回共享伺服器。 第二個開發者在推送修改之前，必須先將第乙個人的工作合併進來，這樣才不會覆蓋第乙個人的修改。 這和 subversion （或任何 cvcs）中的概念一樣，而且這個模式也可以很好地運用到 git 中。
如果在公司或者團隊中，你已經習慣了使用這種集中式工作流程，完全可以繼續採用這種簡單的模式。 只需要搭建好乙個中心倉庫，並給開發團隊中的每個人推送資料的許可權，就可以開展工作了。git 不會讓使用者覆蓋彼此的修改。 例如 john 和 jessica 同時開始工作。 john 完成了他的修改並推送到伺服器。 接著 jessica 嘗試提交她自己的修改，卻遭到伺服器拒絕。 她被告知她的修改正通過非快進式（non-fast-forward）的方式推送，只有將資料抓取下來並且合併後方能推送。 這種模式的工作流程的使用非常廣泛，因為大多數人對其很熟悉也很習慣。
當然這並不侷限於小團隊。 利用 git 的分支模型，通過同時在多個分支上工作的方式，即使是上百人的開發團隊也可以很好地在單個專案上協作。
git 允許多個遠端倉庫存在，使得這樣一種工作流成為可能：每個開發者擁有自己倉庫的寫許可權和其他所有人倉庫的讀許可權。 這種情形下通常會有個代表`『官方』'專案的權威的倉庫。 要為這個專案做貢獻，你需要從該專案轉殖出乙個自己的公開倉庫，然後將自己的修改推送上去。 接著你可以請求官方倉庫的維護者拉取更新合併到主專案。 維護者可以將你的倉庫作為遠端倉庫新增進來，在本地測試你的變更，將其合併入他們的分支並推送回官方倉庫。 這一流程的工作方式如下所示：
專案維護者推送到主倉庫
貢獻者轉殖此倉庫，做出修改
貢獻者將資料推送到自己的公開倉庫
貢獻者給維護者傳送郵件，請求拉取自己的更新
維護者在自己本地的倉庫中，將貢獻者的倉庫加為遠端倉庫並合併修改
維護者將合併後的修改推送到主倉庫
這是 github 和 gitlab 等集線器式（hub-based）工具最常用的工作流程。人們可以容易地將某個專案派生成為自己的公開倉庫，向這個倉庫推送自己的修改，並為每個人所見。 這麼做最主要的優點之一是你可以持續地工作，而主倉庫的維護者可以隨時拉取你的修改。 貢獻者不必等待維護者處理完提交的更新——每一方都可以按照自己節奏工作。
分布式 Git 分布式工作流程
同傳統的集中式版本控制系統 cvcs 不同，開發者之間的協作方式因著 git 的分布式特性而變得更為靈活多樣。在集中式系統上，每個開發者就像是連線在集線器上的節點，彼此的工作方式大體相像。而在 git 網路中，每個開發者同時扮演著節點和集線器的角色，這就是說，每乙個開發者都可以將自己的 貢獻到另外乙...
分布式 Git 分布式工作流程
你現在擁有了乙個遠端 git 版本庫，能為所有開發者共享 提供服務，在乙個本地工作流程下，你也已經熟悉了基本 git 命令。你現在可以學習如何利用 git 提供的一些分布式工作流程了。這一章中，你將會學習如何作為貢獻者或整合者，在乙個分布式協作的環境中使用 git。你會學習為乙個專案成功地貢獻 並接...
深入理解分布式事務
碼農網 吳極心 當資料庫單錶一年產生的資料超過1000w，那麼就要考慮分庫分表，具體分庫分表的原理在此不做解釋，以後有空詳細說，簡單的說就是原來的乙個資料庫變成了多個資料庫。這時候，如果乙個操作既訪問01庫，又訪問02庫，而且要保證資料的一致性，那麼就要用到分布式事務。所謂的soa化，就是業務的服務...