前言
git 依靠分布式版本控制、以及出眾的分支功能受到網際網路開發們的青睞，如果你上過 github 就離不開 git 的相關操作。
我司原來用的是 svn ，經過兩年的時間，全項目都已換成 git ，我現在個人項目也全部用 github 和 gitee 。
但是，隨著需求迭代周期的不斷變化、發布的嚴格管控、線上問題的緊急修復等，開發分支時刻面臨著來自不同需求方的「挑戰」，合併到生產分支有時總會出現不可控的問題。
這些問題對開發人員管控代碼造成了「不小的困擾」。歸根到底就是沒有對 git branch 的開發合併策略有個系統的認識。
借如下這張圖，聊下 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 修復，是不可靠的，因為整個團隊的開發分支是不斷在前行的。
不用去關心 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)
關於我
一名工作在一線的前端工程師，樂於實踐、分享前端相關的技術。歡迎評論留言，願與各位交流進步。