Git工程開發實踐（五）——Git分布式工作流程

Git工程開發實踐（五）——Git分布式工作流程

一、Git分布式工作流程簡介

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

二、Git集中式工作流程

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

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

三、集成管理者工作流程

Git允許多個遠程倉庫存在，每個開發者擁有自己倉庫的寫權限和其他所有人倉庫的讀權限。集成管理者工作流程中，通常會有個官方項目的權威倉庫。如果要為項目做貢獻，需要從官方項目克隆（Fork）出一個自己的公開倉庫，然后將自己的修改推送到自己的公開倉庫；然后可以請求官方倉庫的維護者拉取自己公開倉庫的更新合并到主項目。維護者可以將貢獻者的公開倉庫作為遠程倉庫添加進來，在本地測試貢獻者的變更，將其合并入維護者的本地倉庫分支并推送到官方倉庫。

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

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

司令官與副官工作流程是多倉庫工作流程的變種，通常擁有數百位協作開發者的超大型項目才會使用，例如著名的Linux 內核項目。被稱為副官(lieutenant)的各個集成管理者分別負責集成項目中的特定部分。所有副官還有一位上級稱為司令官(dictator)的總集成管理者負責統籌。司令官維護的倉庫作為參考倉庫，為所有協作者提供需要拉取的項目代碼。

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