【乾貨分享】大話團隊的GIT分支策略進化史

 

封面

做爲一名85後的技術男，一轉眼10年過去了（一不當心暴露了年齡，雖然我叫18歲fantasy），親手寫代碼已是5年前了，目前主要負責公司的軟件產品的規劃和設計（因此最近寫的東西也主要與設計和產品分析有關）並帶着研發團隊進行產品落地。偶爾手癢癢寫點代碼或者和團隊討論一下架構設計啥的，畢竟之前是那麼的熱愛！

這篇文章主要想寫寫我所在團隊git的使用歷程，有些算是回憶吧。~老司機共勉啊~

SVN時代

在剛進公司的時候，那會你們都還在使用svn。代碼，原型設計和過程文檔都在svn上。大概過了一年，整合svn大小40個G（大概兩個千萬級項目的代碼和文檔），每次更新要人命，也給實施團隊和方案團隊帶來了不少困惑，後來就直接把研發從svn上分出來了，但仍是svn管理，svn只用來作內部文檔管理。

那個時候主要面對項目開發，團隊也比較集中，都在北京，項目的特徵就是一次性交付，後面有部分變動開發和bug修改。因此從分支上來講基本上就是這樣的。

單項目svn

你們都在主分支上開發，而後定時提交，到了上線節點QA把代碼checkout下來開始測試。測試完後把bug清單發給研發，研發一頓改，以後提交，QA再回歸測試，基本上沒問題而後就上線了。

暴露問題：

隨着時間的發展，你們有很多時間花在解決衝突上，由於其餘人提交了有bug的代碼（團隊有要求必須自測後提交但，可是自測能力良莠不齊），有時候量大了能折騰一上午，基本上最後提交以前都得先本地備份一下，生怕應爲衝突而代碼丟失了。

引入GIT

隨着業務的擴展和團隊的發展，北京，武漢，長春都有了研發基地，這種扯皮的事情更多了，而且因爲網絡的不穩定，不少時候代碼提交都出現了問題，經過內部溝通研究，決定將代碼管理從svn遷移到公網碼雲（gitee）上，當時也研究了github之類的。最好考慮仍是用了國內的，畢竟還有社區啥的，平時吐個槽看個科技前言新聞也方便。

上了git以後，一開始也只解決了地域問題，你們能夠在各自的城市暢通無阻的提交代碼了，同時團隊也增強了代碼審覈和自測培訓。可是基本上沒有分支的概念，那個時候，GIT的使用是這樣的。

gitc之初

此階段解決的問題：

分佈式團隊，分佈式提交。

產生的問題：因爲團隊要求天天代碼必須提交到遠程。可是自測結果任然具備不肯定，bug仍是滿天飛，天天一來仍是要處理衝突。

引入分支

經過團隊討論，代碼天天下班遠程提交是必須的，爲了防止影響別人，就引入我的分支（團隊任務基本上按人按模塊分工，先後端不分離），因而就給了每一個人或者開發同一個模塊的幾我的建一個分支（若是同一個分支幾我的之間有小矛盾內部本身解決吧），那個時候起名通常按照「項目名_模塊名」起名，好比：dxplat_logmgr（下文暫時用git的專用名稱feature代替）。天天寫完代碼，若是還沒完成就先提交，而後肯定測試完以後再合併到主分支。

引入分支

解決的問題：

可按地域分佈式提交。

可遠程提交到本身的分支，不影響主分支。

產生的問題：

項目上線後，一個項目實施（簡稱A）完以後，另一個相同業務的項目（B）也中標了，可是需求還不盡相同。而且A項目在質保期，還得修修改改，添添補補。怎麼能同時知足這兩個項目併發升級上線呢。若是按照之前的方法，就是管你A和B，我就是一個工程，而後最後都是打一個包給你（說到這不少人應該有同感），同時包含A+B。實施人員你去部署吧，上線配置當心點改，A項目改A的參數，B項目改B的參數。

隨着時間的推移，同業務域定製的項目愈來愈多，這樣下去不是辦法，因爲上線時間不一致，主分支都不敢隨便提交了，QA正在測試A項目的時候B項目也催的着急，也得提交代碼讓另一個AQ測試啊。並且代碼也慢慢失控了，改起來別提多費勁了，各類依賴包整的項目臃腫的不行不行的了。

引入release分支

團隊討論以後，決定引入release分支，一個項目上線後，經過master創建release分支用來支撐不一樣需求的項目，定時選擇性的將不一樣項目裏面的模塊合併到master，開發人員都基於release作開發，而且這個release會一直保留，由於用戶永遠都有當心思。同時新的項目來了以後都從mater再建立release去應付新的定製需求。整個開發流程變成下面的狀況：

release

至此這個策略用了至少2年，一直堅持在用。而且對待項目型的開發整體感受用着還行，網上有人說少了dev分支，團隊內部討論總體感受對項目型不必再搞個dev分支，由於項目基本上是瀑布式開發直到上線，中間迭代上先次數基本不多，要上線也是全部需求知足直接上先。可是最後仍是用上了。

接着往下發展~

終於公司部分業務產品化了，也面向公衆和企業用戶了。需求也多了，面對競爭對手也必須快準狠的面對市場了。

總結產品和項目不一樣的特徵以下：

一、項目具備固定週期，項目結項完畢，開發工做也基本結束了，後期修修補補。產品固然也有周期，可是不是客戶定的週期，而是企業戰略和市場決定。

二、項目基本瀑布式開發，而產品若是競爭激烈，那就必須敏捷迭代，對需求池進行排序，快速跟進。

三、產品和項目都具備可複製特性。可是項目的複製因爲客戶需求的不一樣，需求範圍有很大的不一樣，也就是所說的定製化程度高，基本上是方案和設計思想的複製，其餘都是大量定製開發。而產品一旦肯定用戶羣和需求痛點這些大方向，基本上是一個線性開發的過程。不斷開發迎合市場和企業戰略的新需求，廢棄不必和過期的老需求。

雲端產品和終端產品的區別：

若是雲端產品，那個全部用戶都會感知一個版本。而若是是終端產品的話，不一樣的終端用戶羣會有不一樣的產品版本，根據公司策略和客戶要求去升級。

那麼對於產品化的分支策略，開發需不停的在完成需求池中需求的開發。市場則需根據市場策略上線不一樣的版本，好比有的功能是技術公關，做爲公司與競爭對手的pk點，就不能過於超前上線，以便被抄襲。有的是用戶最關心就必須在競爭對手以前上線。

這個時候之前的分支策略問題就來了。必須有一個分支是時刻能上線的代碼，並且能記錄不一樣的版本（有的版本上線後有bug，須要修改，可是用戶也不須要新功能）。

引入TAG

經過在mater上記錄tag來記錄每次上市的產品版本，若是這個版本有bug，可是用戶當前不須要新的需求，就直接在這個tag上建立臨時的分支給用戶改bug，改完以後代碼將代碼合併到master。這個時候咱們通常不刪除這個臨時分支，由於鬼知道後面還有啥bug呢，有點相似於release分支，可是和release不一樣的是，這個只用來改bug，新的功能開發都必須在mater上。開發流程就變成了這樣：

產品化分支策略

這裏面的問題就是QA測試的時候master不能合併新的代碼只能改bug。一旦合併新的功能，上線範圍就變了，就得從新測試。必須測試完打上tag以後才行。可是有時候公司內部須對全功能進行內部演示和訪談調研，就必須有一個全版本的分鐘，而mater做爲發佈版本，又能隨便合併。怎麼辦呢，就是引入dev分支。

引入DEV分支

具體作法就是建立dev分支，版本上線是，合併到mater，QA從mater上pull代碼作測試用於測試上線，有bug建分支改，改完bug，master和dev上都合併。可是這個時候dev上開發的新模塊不合併到mater，你們提交仍是往dev上提交，內部演示都從dev打包作演示。下次上線依然是提交到mater讓QA測試（這一塊和網上不少人說的不同，你們都是從dev上作測試，而後沒問題合併到mater）。這樣下來分支就變成這樣：

dev分支

有些地方會和網上的會有差異，好比咱們是在最後才引入dev分支的。

總結

一、針對項目和產品咱們採用了兩套策略，項目用release策略，產品用tag策略。

二、另外若是是集中式開發的小團隊小項目，只基於mater開發也不是不可，也挺靈活，加上嚴格的代碼審覈和自檢培訓就好了。

三、這裏面基本也用到GIT的三種工做流的思想（Git Flow，GitHub Flow，GitLab Flow），加入了本身的一些實踐和定製。

關於pull request

對於git中的pull request協做機制，實際應用中也基本沒用上，感受比較適合外包或者開源協做項目（多個不太熟悉的小團隊合做開發一個項目）。若是是內部團隊，畢竟這種協同機制內部定死也不必線上處理了。

咱們的代碼審覈時間有時候不在上線前，基本上會週五或者週一由專人進行（一方面審覈代碼及完善審覈規則，一方面培訓新人），而並非提交一個模塊就讓人審覈，這樣若是功能點太多，審覈人的時間就很零碎。可是上線的功能確定是審覈過了的，並且會有嚴格的代碼測試。

---

零零碎碎也了不少，歡迎你們一塊兒討論吧，有問題也歡迎留言提出。

總之，適合本身團隊和公司的就是最好的，用發展的眼光看待技術。