談談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 上的功能了。這個時候的提交記錄應該是這樣的：

爲何有 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 時，產生代碼衝突。

爲何會產生衝突

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

修復衝突

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

• 當前分支：在控制檯輸入 git merge 命令時的分支，GitLab 上的 target branch
• 合併進來的分支：git merge 命令後的分支，GitLab 上的 source branch

結語

本文是某一次本身忽然想到爲何要有 master 分支來對應生產環境，由於咱們項目會在 master 分支上打 tag，我就想，在 dev 上打也是能夠的，爲何要這樣作，因而有了寫下這篇文章的念頭。

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

後面會繼續寫一些這類的內心活動，若是你以爲喜歡點個贊再走吧，若是有其餘想要了解的部分，歡迎評論留言。