Git工程開發(fā)實(shí)踐（五）——Git分布式工作流程

Git工程開發(fā)實(shí)踐（五）——Git分布式工作流程

一、Git分布式工作流程簡(jiǎn)介

與集中式版本控制系統(tǒng)(CVCS)不同，Git的分布式特性使得開發(fā)者間的協(xié)作變得更加靈活多樣。在集中式系統(tǒng)中，每個(gè)開發(fā)者就像是連接在集線器上的節(jié)點(diǎn)，彼此的工作方式大體相同。 而在Git中，每個(gè)開發(fā)者同時(shí)扮演著節(jié)點(diǎn)和集線器的角色，即每個(gè)開發(fā)者既可以將自己的代碼貢獻(xiàn)到其它的倉(cāng)庫(kù)中，同時(shí)也能維護(hù)自己的公開倉(cāng)庫(kù)，讓其他人可以在其基礎(chǔ)上工作并貢獻(xiàn)代碼。 因此，Git的分布式協(xié)作可以為項(xiàng)目和團(tuán)隊(duì)衍生出各種不同的工作流程。常見的Git分布式工作流程有集中式工作流程、集成管理者工作流程、司令官與副官工作流程。

二、Git集中式工作流程

集中式工作流很好地借鑒了集中式版本控制系統(tǒng)的工作模式。集中式工作流通常包含一個(gè)中央服務(wù)器，可以接受代碼；每個(gè)開發(fā)者作為一個(gè)節(jié)點(diǎn)，將自己的工作與中央服務(wù)器同步。如果兩個(gè)開發(fā)者從中心倉(cāng)庫(kù)克隆代碼下來，同時(shí)作了一些修改，那么只有第一個(gè)開發(fā)者可以順利地把數(shù)據(jù)推送回中央服務(wù)器。 第二個(gè)開發(fā)者在推送修改前，必須先將第一個(gè)人的工作合并進(jìn)來，才不會(huì)覆蓋第一個(gè)人的修改。

集中式工作流程只需要搭建好一個(gè)中心倉(cāng)庫(kù)，并給開發(fā)團(tuán)隊(duì)中的每個(gè)人推送數(shù)據(jù)的權(quán)限，就可以開展工作。Git不會(huì)讓用戶覆蓋彼此的修改。 例如John和Jessica同時(shí)開始工作。 John完成了自己的修改并推送到服務(wù)器。 接著Jessica嘗試提交自己的修改，卻遭到服務(wù)器拒絕。Jessica會(huì)被告知她的修改正通過非快進(jìn)式(non-fast-forward)的方式推送，只有將數(shù)據(jù)抓取下來并且合并后方能推送。
集中式工作流程使用非常廣泛，大多數(shù)人對(duì)其很熟悉也很習(xí)慣。但集中式工作流程并不局限于小團(tuán)隊(duì)，通過利用Git分支模型管理，通過同時(shí)在多個(gè)分支上工作的方式，即使上百人的開發(fā)團(tuán)隊(duì)也可以很好地在單個(gè)項(xiàng)目上協(xié)作。

三、集成管理者工作流程

Git允許多個(gè)遠(yuǎn)程倉(cāng)庫(kù)存在，每個(gè)開發(fā)者擁有自己倉(cāng)庫(kù)的寫權(quán)限和其他所有人倉(cāng)庫(kù)的讀權(quán)限。集成管理者工作流程中，通常會(huì)有個(gè)官方項(xiàng)目的權(quán)威倉(cāng)庫(kù)。如果要為項(xiàng)目做貢獻(xiàn)，需要從官方項(xiàng)目克?。‵ork）出一個(gè)自己的公開倉(cāng)庫(kù)，然后將自己的修改推送到自己的公開倉(cāng)庫(kù)；然后可以請(qǐng)求官方倉(cāng)庫(kù)的維護(hù)者拉取自己公開倉(cāng)庫(kù)的更新合并到主項(xiàng)目。維護(hù)者可以將貢獻(xiàn)者的公開倉(cāng)庫(kù)作為遠(yuǎn)程倉(cāng)庫(kù)添加進(jìn)來，在本地測(cè)試貢獻(xiàn)者的變更，將其合并入維護(hù)者的本地倉(cāng)庫(kù)分支并推送到官方倉(cāng)庫(kù)。

集成管理者工作流程工作方式如下：
A、貢獻(xiàn)者克隆官方主倉(cāng)庫(kù)到自己本地。
B、貢獻(xiàn)者在自己本地倉(cāng)庫(kù)進(jìn)行修改，并推送到自己公開倉(cāng)庫(kù)。
C、貢獻(xiàn)者給維護(hù)者發(fā)送郵件，請(qǐng)求拉取自己的更新。
D、維護(hù)者在自己本地的倉(cāng)庫(kù)中，將貢獻(xiàn)者的公開倉(cāng)庫(kù)加為遠(yuǎn)程倉(cāng)庫(kù)并合并修改。
E、維護(hù)者將合并后的修改推送到官方主倉(cāng)庫(kù)。
集成管理者工作流程是GitHub和GitLab等在線代碼托管工具最常用的工作流程，非常適合社區(qū)開源項(xiàng)目的開發(fā)。Pull Request和Merge Request就是集成管理者工作流程的最佳工程實(shí)踐。
貢獻(xiàn)者可以容易地將某個(gè)項(xiàng)目派生成為自己的公開倉(cāng)庫(kù)，向自己的公開倉(cāng)庫(kù)推送自己的修改，并為每個(gè)人所見。貢獻(xiàn)者可以持續(xù)地工作，而主倉(cāng)庫(kù)的維護(hù)者可以隨時(shí)拉取貢獻(xiàn)者的修改。貢獻(xiàn)者不必等待維護(hù)者處理完提交的更新，每一方都可以按照自己節(jié)奏工作 。

四、司令官與副官工作流程

司令官與副官工作流程是多倉(cāng)庫(kù)工作流程的變種，通常擁有數(shù)百位協(xié)作開發(fā)者的超大型項(xiàng)目才會(huì)使用，例如著名的Linux 內(nèi)核項(xiàng)目。被稱為副官(lieutenant)的各個(gè)集成管理者分別負(fù)責(zé)集成項(xiàng)目中的特定部分。所有副官還有一位上級(jí)稱為司令官(dictator)的總集成管理者負(fù)責(zé)統(tǒng)籌。司令官維護(hù)的倉(cāng)庫(kù)作為參考倉(cāng)庫(kù)，為所有協(xié)作者提供需要拉取的項(xiàng)目代碼。

司令官與副官工作流程如下：
A、普通開發(fā)者在自己的特性分支上工作，并根據(jù)司令官的master分支進(jìn)行變基。
B、副官將普通開發(fā)者的特性分支合并到自己master分支中。
C、司令官將所有副官的master分支并入自己master分支中。
D、司令官將集成后的master分支推送到參考倉(cāng)庫(kù)中，以便所有其他開發(fā)者以此為基礎(chǔ)進(jìn)行變基。
司令官與副官工作流程并不常用，只有當(dāng)項(xiàng)目極為龐雜或者需要多級(jí)別管理時(shí)才會(huì)體現(xiàn)出優(yōu)勢(shì)。利用司令官與副官工作流程，項(xiàng)目總負(fù)責(zé)人(司令官)可以把大量分散的集成工作委托給不同小組負(fù)責(zé)人分別處理，然后在不同時(shí)刻將大塊的代碼子集統(tǒng)籌起來，用于后續(xù)整合。