Git 分布式工作流程

同傳統(tǒng)的集中式版本控制系統(tǒng)（CVCS）不同，開發(fā)者之間的協(xié)作方式因著 Git 的分布式特性而變得更為靈活多樣。在集中式系統(tǒng)上，每個(gè)開發(fā)者就像是連接在集線器上的節(jié)點(diǎn)，彼此的工作方式大體相像。而在 Git 網(wǎng)絡(luò)中，每個(gè)開發(fā)者同時(shí)扮演著節(jié)點(diǎn)和集線器的角色，這就是說，每一個(gè)開發(fā)者都可以將自己的代碼貢獻(xiàn)到另外一個(gè)開發(fā)者的倉庫中，或者建立自己的公共倉庫，讓其他開發(fā)者基于自己的工作開始，為自己的倉庫貢獻(xiàn)代碼。于是，Git 的分布式協(xié)作便可以衍生出種種不同的工作流程，我會(huì)在接下來的章節(jié)介紹幾種常見的應(yīng)用方式，并分別討論各自的優(yōu)缺點(diǎn)。你可以選擇其中的一種，或者結(jié)合起來，應(yīng)用到你自己的項(xiàng)目中。

集中式工作流

通常，集中式工作流程使用的都是單點(diǎn)協(xié)作模型。一個(gè)存放代碼倉庫的中心服務(wù)器，可以接受所有開發(fā)者提交的代碼。所有的開發(fā)者都是普通的節(jié)點(diǎn)，作為中心集線器的消費(fèi)者，平時(shí)的工作就是和中心倉庫同步數(shù)據(jù)（見圖 5-1）。

圖 5-1. 集中式工作流

如果兩個(gè)開發(fā)者從中心倉庫克隆代碼下來，同時(shí)作了一些修訂，那么只有第一個(gè)開發(fā)者可以順利地把數(shù)據(jù)推送到共享服務(wù)器。第二個(gè)開發(fā)者在提交他的修訂之前，必須先下載合并服務(wù)器上的數(shù)據(jù)，解決沖突之后才能推送數(shù)據(jù)到共享服務(wù)器上。在 Git 中這么用也決無問題，這就好比是在用 Subversion（或其他 CVCS）一樣，可以很好地工作。

如果你的團(tuán)隊(duì)不是很大，或者大家都已經(jīng)習(xí)慣了使用集中式工作流程，完全可以采用這種簡單的模式。只需要配置好一臺(tái)中心服務(wù)器，并給每個(gè)人推送數(shù)據(jù)的權(quán)限，就可以開展工作了。但如果提交代碼時(shí)有沖突， Git 根本就不會(huì)讓用戶覆蓋他人代碼，它直接駁回第二個(gè)人的提交操作。這就等于告訴提交者，你所作的修訂無法通過快進(jìn)（fast-forward）來合并，你必須先拉取最新數(shù)據(jù)下來，手工解決沖突合并后，才能繼續(xù)推送新的提交。 絕大多數(shù)人都熟悉和了解這種模式的工作方式，所以使用也非常廣泛。

集成管理員工作流

由于 Git 允許使用多個(gè)遠(yuǎn)程倉庫，開發(fā)者便可以建立自己的公共倉庫，往里面寫數(shù)據(jù)并共享給他人，而同時(shí)又可以從別人的倉庫中提取他們的更新過來。這種情形通常都會(huì)有個(gè)代表著官方發(fā)布的項(xiàng)目倉庫（blessed repository），開發(fā)者們由此倉庫克隆出一個(gè)自己的公共倉庫（developer public），然后將自己的提交推送上去，請求官方倉庫的維護(hù)者拉取更新合并到主項(xiàng)目。維護(hù)者在自己的本地也有個(gè)克隆倉庫（integration manager），他可以將你的公共倉庫作為遠(yuǎn)程倉庫添加進(jìn)來，經(jīng)過測試無誤后合并到主干分支，然后再推送到官方倉庫。工作流程看起來就像圖 5-2 所示：

1. 項(xiàng)目維護(hù)者可以推送數(shù)據(jù)到公共倉庫 blessed repository。
2. 貢獻(xiàn)者克隆此倉庫，修訂或編寫新代碼。
3. 貢獻(xiàn)者推送數(shù)據(jù)到自己的公共倉庫 developer public。
4. 貢獻(xiàn)者給維護(hù)者發(fā)送郵件，請求拉取自己的最新修訂。
5. 維護(hù)者在自己本地的 integration manger 倉庫中，將貢獻(xiàn)者的倉庫加為遠(yuǎn)程倉庫，合并更新并做測試。
6. 維護(hù)者將合并后的更新推送到主倉庫 blessed repository。

圖 5-2. 集成管理員工作流

在 GitHub 網(wǎng)站上使用得最多的就是這種工作流。人們可以復(fù)制（fork 亦即克隆）某個(gè)項(xiàng)目到自己的列表中，成為自己的公共倉庫。隨后將自己的更新提交到這個(gè)倉庫，所有人都可以看到你的每次更新。這么做最主要的優(yōu)點(diǎn)在于，你可以按照自己的節(jié)奏繼續(xù)工作，而不必等待維護(hù)者處理你提交的更新；而維護(hù)者也可以按照自己的節(jié)奏，任何時(shí)候都可以過來處理接納你的貢獻(xiàn)。

司令官與副官工作流

這其實(shí)是上一種工作流的變體。一般超大型的項(xiàng)目才會(huì)用到這樣的工作方式，像是擁有數(shù)百協(xié)作開發(fā)者的 Linux 內(nèi)核項(xiàng)目就是如此。各個(gè)集成管理員分別負(fù)責(zé)集成項(xiàng)目中的特定部分，所以稱為副官（lieutenant）。而所有這些集成管理員頭上還有一位負(fù)責(zé)統(tǒng)籌的總集成管理員，稱為司令官（dictator）。司令官維護(hù)的倉庫用于提供所有協(xié)作者拉取最新集成的項(xiàng)目代碼。整個(gè)流程看起來如圖 5-3 所示：

1. 一般的開發(fā)者在自己的特性分支上工作，并不定期地根據(jù)主干分支（dictator 上的 master）衍合。
2. 副官（lieutenant）將普通開發(fā)者的特性分支合并到自己的 master 分支中。
3. 司令官（dictator）將所有副官的 master 分支并入自己的 master 分支。
4. 司令官（dictator）將集成后的 master 分支推送到共享倉庫 blessed repository 中，以便所有其他開發(fā)者以此為基礎(chǔ)進(jìn)行衍合。

 圖 5-3. 司令官與副官工作流

這種工作流程并不常用，只有當(dāng)項(xiàng)目極為龐雜，或者需要多級(jí)別管理時(shí)，才會(huì)體現(xiàn)出優(yōu)勢。利用這種方式，項(xiàng)目總負(fù)責(zé)人（即司令官）可以把大量分散的集成工作委托給不同的小組負(fù)責(zé)人分別處理，最后再統(tǒng)籌起來，如此各人的職責(zé)清晰明確，也不易出錯(cuò)（譯注：此乃分而治之）。

以上介紹的是常見的分布式系統(tǒng)可以應(yīng)用的工作流程，當(dāng)然不止于 Git。在實(shí)際的開發(fā)工作中，你可能會(huì)遇到各種為了滿足特定需求而有所變化的工作方式。我想現(xiàn)在你應(yīng)該已經(jīng)清楚，接下來自己需要用哪種方式開展工作了。下節(jié)我還會(huì)再舉些例子，看看各式工作流中的每個(gè)角色具體應(yīng)該如何操作。