談談 Git 分支管理的本質

想了想工作兩年中自己做的事情，發現這方面還算不錯，所以拎出來說說自己對 Git 的一些理解。

粗略瀏覽了一下網上存在的 Git 相關的中文文章，大多數是介紹 Git 的一些命令怎麼使用，或者是介紹 Git 分支管理策略裏有哪些類型的分支，似乎沒有一篇文章是在解釋爲什麼要這麼做。

我想從這個角度來寫一篇文章，記錄 Git 分支管理裏那些最本質的思想，如果在學習過程中能夠直觀性瞭解到這個層面，在學習任何東西時，都會有事半功倍的效果吧。

爲什麼有 hotfix 分支

我們先來看看爲什麼有 hotfix 分支。

假設我們只有一條分支 dev，最新的提交記錄是 A000001，以該提交記錄打了一個 tag 1.0，然後我們基於這個節點的版本發佈了系統。

我們繼續在 dev 分支上繼續開發，有了 A000002、A000003 兩個新的提交記錄，在這個時候線上系統發現了一個 BUG ，我們要如何修復？

如果是單獨的一個 dev 分支，我們可以回滾到 A000001 這個時候的版本修復 BUG，提交記錄爲 A000004，然後部署生產版本。那麼此時就有一個問題，A000002 和 A000003 的提交記錄就會被丟掉了，怎麼辦？

PS：寫這篇文章的時候沒有實際測試過，所以不知道這種情況的這兩個分支會如何處理，下次一定先測試。

所以對於線上 BUG，分支管理策略裏採取的是基於生產分支創建一個分支（一般取前綴 hotfix-），然後基於該分支修復 BUG 並提交，再基於這個最新的提交記錄 A000004 發佈系統，將 hotfix 分支合併到 dev 分支裏，這樣就不會影響後來開發的 A000002、A000003 上的功能了。這個時候的提交記錄應該是這樣的：

圖 1

爲什麼有 master/pro 分支

如果是一個分支管理所有版本，上面我們合併 Hotfix 分支到 dev 後，就把它刪掉。這個時候，線上又發現了一個 BUG，我們又得修復，我們怎麼創建新的 hotfix 分支？如果從 A000001 創建，那我們丟了 A000004 裏修復的代碼，如果從 dev 創建，那會將正在開發中的 A000002 和 A000003 也發到線上，造成線上環境存在着不需要的代碼，所以呢，我們得有一個分支來對應線上環境，所以就有了 master/pro 分支，對應的是線上環境的代碼。

爲什麼要合併 hotfix 分支兩次

參看圖 1，我們可以知道，分支一旦被切出來以後，兩個分支未來的發展是相互獨立的，除非是將兩個分支合併。所以爲了保證代碼的完整性，在非環境對應分支（如：dev、master 等）下開發的代碼，需要合併至環境對應的分支裏，一般採取的是，從哪切出來的分支，最後合併到哪個分支中去。

爲什麼從 master 切 hotifx 分支

在有了 master 及 dev 分支分別對應線上環境及開發環境 後，我們修復線上 BUG 就得從 master 分支上切出 hotfix 分支來進行修復，如果這個時候我們也可以回滾 dev 分支切出 hotfix 分支也是可以的，但是從 master 切分支明顯更快更方便。

爲什麼要合併 hotfix 分支到 dev 分支

在理解了爲什麼要進行合併操作以後，在 hotfix 分支修復了 BUG 以後，就會將代碼合併回 master 分支，準備部署發版，那爲什麼要將 hotfix 分支合併到 dev 中？

這一步的操作，更多的是保證 dev 的代碼跟 master 一致，避免未來合併 dev 分支到 master 時，產生代碼衝突。

爲什麼會產生衝突

圖 2

如圖 2，合併時產生衝突我們可以簡單的理解爲：假如在 A000006 和 A000007 兩次記錄中，都對 文件 A 的 line: 2 進行過修改，這個時候我們將 hotfix 合併至 dev 中，Git 不知道我們應該保留兩個提交記錄中的哪一個版本，所以提示我們有衝突，需要我們來選擇一個版本的記錄保留下來。

修復衝突

簡單的衝突我們可以選擇 accept current、accept incoming 或 accept both 中的一種方式，分別是保留 當前分支的代碼、合併進來的分支中的代碼 和 兩個分支中的版本都保留。

結語

本文是某一次自己突然想到爲什麼要有 master 分支來對應生產環境，因爲我們項目會在 master 分支上打 tag，我就想，在 dev 上打也是可以的，爲什麼要這樣做，於是有了寫下這篇文章的念頭。

之所以寫下這篇文章，也是因爲想把這種思考的點分享出來，讓其他學起來沒那麼快，或者對 Git 分支管理有疑問的人，有一個瞭解途徑。

原文鏈接：https://juejin.im/post/5efd9d945188252e974ee581

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/TmqSi4QT1vCZ5G1ZQpvHPQ

猜你喜歡