第4章 分布式Git
4.1 分布式 Git - 分布式工作流程
你現在擁有了一個遠程 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 等分布式系統中經常使用的工作流程，但是在實際的開發中，你會遇到許多可能適合你的特定工作流程的變種。 現在你應該已經清楚哪種工作流程組合可能比較適合你了，我們會給出一些如何扮演不同工作流程中主要角色的更具體的例子。 下一節我們將會學習為項目做貢獻的一些常用模式。
4.2 分布式 Git - 向一個項目貢獻
向一個項目貢獻
描述如何向一個項目貢獻的主要困難在于完成貢獻有很多不同的方式。 因為 Git 非常靈活，人們可以通過不同的方式來一起工作，所以描述應該如何貢獻并不是非常準確——每一個項目都有一點兒不同。 影響因素包括活躍貢獻者的數量、選擇的工作流程、提交權限與可能包含的外部貢獻方法。
第一個影響因素是活躍貢獻者的數量——積極地向這個項目貢獻代碼的用戶數量以及他們的貢獻頻率。 在許多情況下，你可能會有兩三個開發者一天提交幾次，對于不活躍的項目可能更少。 對于大一些的公司或項目，開發者的數量可能會是上千，每天都有成百上千次提交。 這很重要，因為隨著開發者越來越多，在確保你的代碼能干凈地應用或輕松地合并時會遇到更多問題。 提交的改動可能表現為過時的，也可能在你正在做改動或者等待改動被批準應用時被合并入的工作嚴重損壞。 如何保證代碼始終是最新的，并且提交始終是有效的？
下一個影響因素是項目使用的工作流程。 它是中心化的嗎，即每一個開發者都對主線代碼有相同的寫入權限？ 項目是否有一個檢查所有補丁的維護者或整合者？ 是否所有的補丁是同行評審后批準的？ 你是否參與了那個過程？ 是否存在副官系統，你必須先將你的工作提交到上面？
下一個影響因素是提交權限。 是否有項目的寫權限會使向項目貢獻所需的流程有極大的不同。 如果沒有寫權限，項目會選擇何種方式接受貢獻的工作？ 是否甚至有一個如何貢獻的規范？ 你一次貢獻多少工作？ 你多久貢獻一次？
所有這些問題都會影響實際如何向一個項目貢獻，以及對你來說哪些工作流程更適合或者可用。 我們將會由淺入深，通過一系列用例來講述其中的每一個方面；從這些例子應該能夠建立實際中你需要的特定工作流程。
提交準則
在我們開始查看特定的用例前，這里有一個關于提交信息的快速說明。 有一個好的創建提交的準則并且堅持使用會讓與 Git 工作和與其他人協作更容易。 Git 項目提供了一個文檔，其中列舉了關于創建提交到提交補丁的若干好的提示——可以在 Git 源代碼中的 Documentation/SubmittingPatches 文件中閱讀它。
首先，你的提交不應該包含任何空白錯誤。 Git 提供了一個簡單的方式來檢查這點——在提交前，運行 git diff --check，它將會找到可能的空白錯誤并將它們為你列出來。
Figure 57. git diff --check 的輸出
如果在提交前運行那個命令，可以知道提交中是否包含可能會使其他開發者惱怒的空白問題。
接下來，嘗試讓每一個提交成為一個邏輯上的獨立變更集。 如果可以，嘗試讓改動可以理解——不要在整個周末編碼解決五個問題，然后在周一時將它們提交為一個巨大的提交。 即使在周末期間你無法提交，在周一時使用暫存區域將你的工作最少拆分為每個問題一個提交，并且為每一個提交附帶一個有用的信息。 如果其中一些改動修改了同一個文件，嘗試使用 git add --patch 來部分暫存文件。 不管你做一個或五個提交，只要所有的改動都曾添加過，項目分支末端的快照就是一樣的，所以盡量讓你的開發者同事們在審查你的改動的時候更容易些吧。
當你之后需要時這個方法也會使拉出或還原一個變更集更容易些。 [重寫歷史]描述了重寫歷史與交互式暫存文件的若干有用的 Git 技巧——在將工作發送給其他人前使用這些工具來幫助生成一個干凈又易懂的歷史。
最后一件要牢記的事是提交信息。 有一個創建優質提交信息的習慣會使 Git 的使用與協作容易的多。 一般情況下，信息應當以少于 50 個字符（25個漢字）的單行開始且簡要地描述變更，接著是一個空白行，再接著是一個更詳細的解釋。 Git 項目要求一個更詳細的解釋，包括做改動的動機和它的實現與之前行為的對比——這是一個值得遵循的好規則。 使用指令式的語氣來編寫提交信息，比如使用“Fix bug”而非“Fixed bug”或“Fixes bug”。 這里是一份 [最初由 Tim Pope 寫的模板]：
首字母大寫的摘要（不多于 50 個字符） ? 如果必要的話，加入更詳細的解釋文字。在大概 72 個字符的時候換行。 在某些情形下，第一行被當作一封電子郵件的標題，剩下的文本作為正文。 分隔摘要與正文的空行是必須的（除非你完全省略正文）， 如果你將兩者混在一起，那么類似變基等工具無法正常工作。 ? 使用指令式的語氣來編寫提交信息：使用“Fix bug”而非“Fixed bug”或“Fixes bug”。 此約定與 git merge 和 git revert 命令生成提交說明相同。 ? 空行接著更進一步的段落。 ? - 標號也是可以的。 ? - 項目符號可以使用典型的連字符或星號，后跟一個空格，行之間用空行隔開，但是可以依據不同的慣例有所不同。 ? - 使用懸掛式縮進
如果你所有的提交信息都遵循此模版，那么對你和與你協作的其他開發者來說事情會變得非常容易。 Git 項目有一個良好格式化的提交信息——嘗試在那兒運行 git log --no-merges 來看看漂亮的格式化的項目提交歷史像什么樣。
| Note | 按我們說的去做，不要照著我們做的去做。為簡單起見，本書中很多例子的提交說明并沒有遵循這樣良好的格式， 我們只是對 git commit 使用了 -m 選項。簡而言之，按我們說的去做，不要照著我們做的去做。 |
|---|---|
私有小型團隊
你可能會遇到的最簡單的配置是有一兩個其他開發者的私有項目。 “私有” 在這個上下文中，意味著閉源——不可以從外面的世界中訪問到。 你和其他的開發者都有倉庫的推送權限。
在這個環境下，可以采用一個類似使用 Subversion 或其他集中式的系統時會使用的工作流程。 依然可以得到像離線提交、非常容易地新建分支與合并分支等高級功能，但是工作流程可以是很簡單的；主要的區別是合并發生在客戶端這邊而不是在提交時發生在服務器那邊。 讓我們看看當兩個開發者在一個共享倉庫中一起工作時會是什么樣子。 第一個開發者，John，克隆了倉庫，做了改動，然后本地提交。 （為了縮短這些例子長度，協議信息已被替換為 …。）
# John's Machine $ git clone john@githost:simplegit.git Cloning into 'simplegit'... ... $ cd simplegit/ $ vim lib/simplegit.rb $ git commit -am 'remove invalid default value' [master 738ee87] remove invalid default value1 files changed, 1 insertions(+), 1 deletions(-)
第二個開發者，Jessica，做了同樣的事情——克隆倉庫并提交了一個改動：
# Jessica's Machine $ git clone jessica@githost:simplegit.git Cloning into 'simplegit'... ... $ cd simplegit/ $ vim TODO $ git commit -am 'add reset task' [master fbff5bc] add reset task1 files changed, 1 insertions(+), 0 deletions(-)
現在，Jessica 把她的工作推送到服務器上，一切正常：
# Jessica's Machine $ git push origin master ... To jessica@githost:simplegit.git1edee6b..fbff5bc master -> master
上方輸出信息中最后一行顯示的是推送操作執行完畢后返回的一條很有用的消息。 消息的基本格式是 <oldref>..<newref> fromref → toref ， oldref 的含義是推送前所指向的引用， newref 的含義是推送后所指向的引用， fromref 是將要被推送的本地引用的名字， toref 是將要被更新的遠程引用的名字。 在后面的討論中你還會看到類似的輸出消息，所以對這條消息的含義有一些基礎的了解將會幫助你理解倉庫的諸多狀態。 想要了解更多細節請訪問文檔 git-push 。
John 稍候也做了些改動，將它們提交到了本地倉庫中，然后試著將它們推送到同一個服務器：
# John's Machine $ git push origin master To john@githost:simplegit.git! [rejected] ? ? ? master -> master (non-fast forward) error: failed to push some refs to 'john@githost:simplegit.git'
這時 John 會推送失敗，因為之前 Jessica 已經推送了她的更改。 如果之前習慣于用 Subversion 那么理解這點特別重要，因為你會注意到兩個開發者并沒有編輯同一個文件。 盡管 Subversion 會對編輯的不同文件在服務器上自動進行一次合并，但 Git 要求你先在本地合并提交。 換言之，John 必須先抓取 Jessica 的上游改動并將它們合并到自己的本地倉庫中，才能被允許推送。
第一步，John 抓取 Jessica 的工作（這只會 抓取 Jessica 的上游工作，并不會將它合并到 John 的工作中）：
$ git fetch origin ... From john@githost:simplegit+ 049d078...fbff5bc master ? ? -> origin/master
在這個時候，John 的本地倉庫看起來像這樣：
Figure 58. John 的分叉歷史
現在 John 可以將抓取下來的 Jessica 的工作合并到他自己的本地工作中了：
$ git merge origin/master Merge made by the 'recursive' strategy.TODO | ? 1 +1 files changed, 1 insertions(+), 0 deletions(-)
合并進行得很順利——John 更新后的歷史現在看起來像這樣：
Figure 59. 合并了 origin/master 之后 John 的倉庫
此時，John 可能想要測試新的代碼，以確保 Jessica 的工作沒有影響他自己的工作， 當一切正常后，他就能將新合并的工作推送到服務器了：
$ git push origin master ... To john@githost:simplegit.gitfbff5bc..72bbc59 master -> master
最終，John 的提交歷史看起來像這樣：
Figure 60. 推送到 origin 服務器后 John 的歷史
在此期間，Jessica 新建了一個名為 issue54 的主題分支，然后在該分支上提交了三次。 她還沒有抓取 John 的改動，所以她的提交歷史看起來像這樣：
Figure 61. Jessica 的主題分支
忽然，Jessica 發現 John 向服務器推送了一些新的工作，她想要看一下， 于是就抓取了所有服務器上的新內容：
# Jessica's Machine $ git fetch origin ... From jessica@githost:simplegitfbff5bc..72bbc59 master -> origin/master
那會同時拉取 John 推送的工作。 Jessica 的歷史現在看起來像這樣：
Figure 62. 抓取 John 的改動后 Jessica 的歷史
Jessica 認為她的主題分支已經準備好了，但她想知道需要將 John 工作的哪些合并到自己的工作中才能推送。 她運行 git log 找了出來：
$ git log --no-merges issue54..origin/master commit 738ee872852dfaa9d6634e0dea7a324040193016 Author: John Smith <jsmith@example.com> Date: Fri May 29 16:01:27 2009 -0700remove invalid default value
issue54..origin/master 語法是一個日志過濾器，要求 Git 只顯示所有在后面分支 （在本例中是 origin/master）但不在前面分支（在本例中是 issue54）的提交的列表。
目前，我們可以從輸出中看到有一個 John 生成的但是 Jessica 還沒有合并的提交。 如果她合并 origin/master，那個未合并的提交將會修改她的本地工作。
現在，Jessica 可以合并她的特性工作到她的 master 分支， 合并 John 的工作（origin/master）進入她的 master 分支，然后再次推送回服務器。
首先（在已經提交了所有 issue54 主題分支上的工作后），為了整合所有這些工作， 她切換回她的 master 分支。
$ git checkout master Switched to branch 'master' Your branch is behind 'origin/master' by 2 commits, and can be fast-forwarded.
Jessica 既可以先合并 origin/master 也可以先合并 issue54 ——它們都是上游，所以順序并沒有關系。 不論她選擇的順序是什么最終的結果快照是完全一樣的；只是歷史會稍微有些不同。 她選擇先合并 issue54：
$ git merge issue54 Updating fbff5bc..4af4298 Fast forwardREADME | 1 +lib/simplegit.rb | 6 +++++-2 files changed, 6 insertions(+), 1 deletions(-)
沒有發生問題，如你所見它是一次簡單的快進合并。 現在 Jessica 在本地合并了之前抓取的 origin/master 分支上 John 的工作：
$ git merge origin/master Auto-merging lib/simplegit.rb Merge made by the 'recursive' strategy.lib/simplegit.rb | 2 +-1 files changed, 1 insertions(+), 1 deletions(-)
每一個文件都干凈地合并了，Jessica 的歷史現在看起來像這樣：
Figure 63. 合并了 John 的改動后 Jessica 的歷史
現在 origin/master 是可以從 Jessica 的 master 分支到達的， 所以她應該可以成功地推送（假設同一時間 John 并沒有更多推送）：
$ git push origin master ... To jessica@githost:simplegit.git72bbc59..8059c15 master -> master
每一個開發者都提交了幾次并成功地合并了其他人的工作。
Figure 64. 推送所有的改動回服務器后 Jessica 的歷史
這是一個最簡單的工作流程。 你通常會在一個主題分支上工作一會兒，當它準備好整合時就合并到你的 master 分支。 當想要共享工作時，如果有改動的話就抓取它然后合并到你自己的 master 分支， 之后推送到服務器上的 master 分支。通常順序像這樣：
Figure 65. 一個簡單的多人 Git 工作流程的通常事件順序
)
