git 分支合併策略

前言

git 依靠分佈式版本控制、以及出眾的分支功能受到互聯網開發們的青睞，如果你上過 github 就離不開 git 的相關操作。

我司原來用的是 svn ，經過兩年的時間，全項目都已換成 git ，我現在個人項目也全部用 github 和 gitee 。

但是，隨著需求迭代週期的不斷變化、發佈的嚴格管控、線上問題的緊急修復等，開發分支時刻面臨著來自不同需求方的“挑戰”，合併到生產分支有時總會出現不可控的問題。

這些問題對開發人員管控代碼造成了“不小的困擾”。歸根到底就是沒有對 git branch 的開發合併策略有個系統的認識。

借如下這張圖，聊下 git 分支合併策略：

git 分支合併策略

相信有和我們一樣的 git 分支合併問題的同學看過這圖後，已經有了解決方案，可以忽略之後的內容了。當然看暈的同學，可以繼續閱讀下去，我會盡可能說清楚其中的方式。

面臨的問題

首先我們前端只是個幾個人的團隊，分支只有如下兩種：

• develop：開發分支
• product：發佈分支

以前就像前面說的一樣，隨著團隊的逐日專業化，不能扛著小槍指哪打哪兒，面對各種“約束”，“困難”產生了如下些問題：

• 在開發資源有限的前提下，面對多個需求，如何管理 develop 分支？
• 線上緊急 bug 的修復（緊急事件對分支的侵入）
• 怎麼維護“相對”穩定的分支，作為發佈分支（發佈分支的管理）
• 線上發佈後，因為某些“不可抗力”的原因，如何快速回滾上個版本（版本回滾）

應對策略

開發分支的細化

在項目“墾荒”階段，或者迭代需求有規律，功能“輕量”時，往往一條開發分支就足夠了（畢竟我們以前都那麼幹的），但產品上線後，面對八方的需求就有些捉襟見肘。

比如： A ， B 兩個需求，A 預估 5 天，B 預估 10 天，但整個開發時間只有 10 天，勢必 AB 兩個需要不同開發人員同時進行。但更不幸的是，第 5 天時就要把 A 推到生產，一條 develop 分支完全不能應對（總不能 B 需求才完成一半），那怎麼管理 develop 分支？

把 A ，B 兩個需求單獨創建分支，這類分支稱為 feature branch ，那我們的 git 代碼提交流程就會變成這樣：

開發分支的細化

分別在 develop 分支上創建兩條 feature 分支，對應 A，B 需求。這樣三條分支在邏輯上互不干涉，如果 feature A 完成後即可推到 develop 上安排測試、發佈等事項，feature B 可以繼續安心的在屬於它的分支上開發。

創建 bug 分支

面對緊急的線上 bug ，可以單獨切一條臨時的分支做處理，好處就是它對線上或者開發分支做的到“零侵入”。因為直接在 develop 上做 bug 修復，是不可靠的，因為整個團隊的開發分支是不斷在前行的。

創建 bug 分支

不用去關心 develop 的開發情況，從發佈分支直接切出一個乾淨的 hotfix 分支，用於 bug 的修復，測試無問題後再推到發佈分支上線。

穩定的預發佈分支

為了防止 product，develop 分支被開發人員在發佈前後修改，造成發佈代碼功能問題，需要一個手段來“凍結”分支，以使其發佈前後穩定。總不希望測試環境一切正常，但發佈到線上卻出現意料之外的問題（這樣的事故，也是蠻那個啥的）。

這樣的分支分為 release branch ：

穩定的預發佈分支

一旦把 develop 合併到 release 預發佈分支，將把注意力放到 release 上，後續一切發現的問題將基於此分支進行，因為線上發佈將以此為可靠穩定的基礎。

為了讓 穩定 不口頭上說說，甚至可以將 release 立為保護分支（protect branch），所有的 push 請求將由項目管理人員來負責審核。

版本回退

和緊急 bug 修復類似，但有些不同。如果某些非開發原因（需求部門臨時決定不上新功能等），需要把線上已發佈的代碼“撤下來”，但開發分支、或者發佈分支都已經經歷多次提交合並，已經難以定位之前的代碼（除非有上次代碼的備份記錄，但這屬於另一個範疇的問題）。需要有一種機制來快速回滾，可能上一次，可能上個月某天的發佈。

為實現快速回滾，就要涉及 git 中 tag 的運用。

tag 顧名思義，給分支當前的狀態打個標。並沒有創建出一個新的節點，只是添加一些“備註”。

如果遇到 B 需求到了上線那天並且發佈了，但因為突發情況需要回退到上次版本，所有的分支都做了合併，注意力都放在 B 需求的迭代，單純的根據提交信息來回退代碼是具有風險性的，最可靠的還是找到上次發佈的代碼來回滾。此時 tag 標籤就發揮作用，如果上次發版在發佈分支打了標籤 1.0，這次就執行如下命令，就輕鬆回退：

git reset --hard 1.0 # 將 HEAD 回退到 tag 1.0 時的代碼狀態
git push --force origin master # 覆蓋主線分支

版本回退

總結

理解 git 分支合併策略將對項目代碼的管控更為“自由”，雖然操作會複雜，但這些卻是一定要做的。相信會在遇到上述這些問題時，起到確定性作用。

參考：

• [git book](https://git-scm.com/book/en/v2)

關於我

一名工作在一線的前端工程師，樂於實踐、分享前端相關的技術。關注【前端雨爸】，歡迎評論留言，願與各位交流進步。

點擊 ↙ 瞭解更多，查看更多相關技術文章