版本管理工具裡面的分支管理一直是困擾開發團隊的一個大問題，這裡我總結了我們團隊使用的分支管理以及開發測試發布環境管理機制。

分支命名和管理

  1. 現有的主線（master），對應的集成測試環境
  2. 新建prod分支，用於對應線上正式環境（生產環境）
  3. 上述兩個分支的代碼和集成，正式環境保持完全一致，如果有版本撤回的操作，代碼也要做對應的操作
  4. 上述兩個分支的合併和發布許可權僅限個別的項目負責人

新開迭代的分支操作流程

  1. 產品經理召開迭代啟動會，確定本次迭代包含的功能和bug範圍
  2. 相關的開發負責人按照迭代編號或者功能名稱從prod創建迭代分支
  3. 相關的開發從迭代分支開自己的分支做開發
  4. 開發完成後，從自己的分支發布功能測試版本（本地或者內網環境）
  5. 功能測試完畢，需要發布集成測試時，先從自己的分支合併到迭代分支，再由項目負責人合併主線，發布集成環境
  6. 集成環境測試通過，項目負責人把主線合併到prod分支，再發布正式

舉例：

  • 產品經理打算開展新的迭代，迭代編號為SL2.0.036
  • 開發主管從涉及到的項目的prod分支分別創建名為「sl2.0.036」的迭代開發分支。
  • 開發人員A從行程的迭代分支「sl2.0.036」再創建自己的開發分支「sl2.0.036_a」，在這個分支上做開發，開發完成後把自己的開發分支「sl2.0.036_a」合併到迭代分支「sl2.0.036」，基於迭代分支發布功能測試站點。
  • 如果還有別的人也參與這個迭代的開發，並且也要改動行程的代碼，比如說B也要參與這個開發。那麼B也從行程的迭代分支「sl2.0.036」創建自己的開發分支「sl2.0.036_b」。
  • 如果A和B的代碼有必要合併之後統一發布一個功能測試站點，那麼A和B分別把自己的分支合併到迭代分支「sl2.0.036」，然後再基於迭代分支發功能測試站點。
  • 功能測試完成後，由開發主管統一負責把這個迭代涉及到的各個項目的迭代分支合併到主線（master）分支。並基於master分支發布集成測試。
  • 集成測試完畢之後，由開發主管負責把涉及到的各個項目的master分支和prod分支合併，然後發布生產環境。
正常迭代分支管理

緊急版本發布操作流程

  1. 從prod切出fix分支，做緊急修復
  2. 從fix分支發布功能測試
    1. 如果改動很小，fix分支直接合併prod，發布正式
    2. 如果需要再做集成測試，那麼fix分支合併到主線，發布集成，做測試，再fix合併到prod，發布正式

舉例：

  • 今天線上客戶反饋機票查詢有問題，經過檢查機票後端需要做修改。
  • 由機票後台的開發A從機票後台項目的prod分支切出緊急修復的分支，緊急修復的分支統一以fix加日期和bug描述命名，比如「fix_20190227經停航班查詢問題」
  • 在緊急修復的分支修改完成後，基於緊急修復的分支發布功能測試站點
  • 功能測試完成後，開發主管把緊急修復的分支合併到master，重新發布集成測試站點
  • 集成測試完成後，開發主管把機票後台項目的「fix_20190227經停航班查詢問題」合併到prod，發布生產環境
緊急發版分支管理

命名約定

  1. 分支名稱裡面的英文都全小寫
  2. 各個項目的master對應集成環境，prod對應生產環境
  3. 緊急修復的分支以fix_+日期+問題描述命名，例如「fix_20190227經停航班查詢問題」
  4. 迭代分支以迭代名命名

關於代碼Review的時機

  • 如果是正常的迭代，在個人的開發分支合併到迭代分支時做review
  • 如果是緊急修復，在個人分支合併到master或者prod的時候做review

關於分支合併

分支合併的原理：不同的分支上包含有不同的提交的改動，兩個分支合併，就是把其中一個分支（A）上的改動都移動到另外一個分支（B）上。比如A和B往回追溯，兩個分支岔開的時間點在一個月之前，那麼把分支A合併到分支B實際上就是A分支上這一個月以來的改動都做到B上。

合併衝突的解決：既然合併代碼的實質是往某個分支上提交一堆改動，那麼就很容易出現各種改動的衝突。一旦出現改動衝突，哪怕只是修改到了同一個文件的不同行，在git裡面也會認為是有需要解決的衝突。比如說A分支包含某個提交，這個提交涉及到a,b,c三個文件的修改，B分支的某個提交涉及到c,d,e三個文件，需要解決的衝突是兩個提交對文件c的修改，但是實際上解決衝突的changelist裡面會把a,b,c,d,e都放出來，解決完c的衝突之後，這五個文件需要重新提交上去。如果不提交a,b,d,e，就會造成所謂的「丟修改」的問題產生。

分支合併實際操作流程：一般來說，分支合併的方向都是從支線往主線合併。比如說迭代分支合併到主線，開發分支合併到迭代分支。但是實際操作時，一般會這麼操作：把支線分支A合併到主線分支B時，一般會先把B往A合併，這樣實際上是把從A切出來之後合併到B的所有改動都移動到了A上，這個合併的過程中可以基本上解決各種衝突，開發甚至可以基於合併之後的A分支再發一版功能測試。然後再把A合併到B就不太會有衝突。

關於Git的分支合併，有機會再開專題討論吧。

推薦閱讀：

相关文章