Git工程開發實踐（五）——Git分佈式工做流程

Git工程開發實踐（五）——Git分佈式工做流程

1、Git分佈式工做流程簡介

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

2、Git集中式工做流程

集中式工做流很好地借鑑了集中式版本控制系統的工做模式。集中式工做流一般包含一箇中央服務器，能夠接受代碼；每一個開發者做爲一個節點，將本身的工做與中央服務器同步。若是兩個開發者從中心倉庫克隆代碼下來，同時做了一些修改，那麼只有第一個開發者能夠順利地把數據推送回中央服務器。 第二個開發者在推送修改前，必須先將第一我的的工做合併進來，纔不會覆蓋第一我的的修改。

集中式工做流程只須要搭建好一箇中心倉庫，並給開發團隊中的每一個人推送數據的權限，就能夠開展工做。Git不會讓用戶覆蓋彼此的修改。 例如John和Jessica同時開始工做。 John完成了本身的修改並推送到服務器。 接着Jessica嘗試提交本身的修改，卻遭到服務器拒絕。Jessica會被告知她的修改正經過非快進式(non-fast-forward)的方式推送，只有將數據抓取下來而且合併後方能推送。
集中式工做流程使用很是普遍，大多數人對其很熟悉也很習慣。但集中式工做流程並不侷限於小團隊，經過利用Git分支模型管理，經過同時在多個分支上工做的方式，即便上百人的開發團隊也能夠很好地在單個項目上協做。

3、集成管理者工做流程

Git容許多個遠程倉庫存在，每一個開發者擁有本身倉庫的寫權限和其餘全部人倉庫的讀權限。集成管理者工做流程中，一般會有個官方項目的權威倉庫。若是要爲項目作貢獻，須要從官方項目克隆（Fork）出一個本身的公開倉庫，而後將本身的修改推送到本身的公開倉庫；而後能夠請求官方倉庫的維護者拉取本身公開倉庫的更新合併到主項目。維護者能夠將貢獻者的公開倉庫做爲遠程倉庫添加進來，在本地測試貢獻者的變動，將其合併入維護者的本地倉庫分支並推送到官方倉庫。

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

4、司令官與副官工做流程

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

司令官與副官工做流程以下：
A、普通開發者在本身的特性分支上工做，並根據司令官的master分支進行變基。
B、副官將普通開發者的特性分支合併到本身master分支中。
C、司令官將全部副官的master分支併入本身master分支中。
D、司令官將集成後的master分支推送到參考倉庫中，以便全部其餘開發者以此爲基礎進行變基。
司令官與副官工做流程並不經常使用，只有當項目極爲龐雜或者須要多級別管理時纔會體現出優點。利用司令官與副官工做流程，項目總負責人(司令官)能夠把大量分散的集成工做委託給不一樣小組負責人分別處理，而後在不一樣時刻將大塊的代碼子集統籌起來，用於後續整合。