轉載 簡書：https://www.jianshu.com/p/d917139304eb

一、前言

本文用例項來講解Git的分支管理在產品快速迭代開發過程中解決實際問題的詳細方案，面向的是對Git有一定了解的朋友（多圖預警）。

二、背景

最近接手了一個程式碼質量慘不忍睹的專案，立即著手進行重構，由於產品已經發布上線，在重構新版的過程中還要一直維護著老版本，所以如何維護好兩個版本的程式碼就成了一個問題。由於我們的團隊一直以來使用Git時都忽視了其最大的優勢 - 分支管理，所以正好趁此機會規範團隊中Git的使用姿勢。

三、關鍵字提示

master指的是本地主分支，也就是我們新建專案首次關聯到Git上的本地主分支；origin/master

四、引出問題

假設我們的產品版本A已經發布上線了，現在我們繼續開發版本B，今天產品經理過來告訴你版本A有一個十萬火急的Bug，這個時候我們肯定是想辦法拿到版本A的程式碼去修復Bug，那麼問題來了：

1、在拿版本A的程式碼時，如何去儲存我們寫到一半的版本B的程式碼？

有的朋友肯定會把寫到一半的程式碼commit到本地去解決這個問題，這是最簡單的方式但是也是錯誤的方式，其僅僅是達到了目的，但是這樣會在版本節點上留下很多垃圾資料，經常會誤導團隊的其他成員。

2、在修改完版本A的Bug後，如何提交這次的修改呢？

在版本A的節點上直接進行commit的話，HEAD指標會遊離出去，也就是我們經常遇見的問題HEAD detached at head或者HEADdetached from master，搞不好會丟失一部分程式碼，如果你已經遇到這個問題了，這裡只提供方案就是找到HEAD現在所指向的未知分支，給其命名，然後合併到master分支上，具體操作自行搜尋。

3、先不管用什麼辦法，假如我在修改完版本A後真的將此次的修改記錄成功提交了，如何恢復我寫到一半的版本B的程式碼呢？

這裡一定有修改完後選擇不提交，直接手動合併到版本B的朋友，目的又達到了，但是這樣會導致此次對

五、解決方案

帶著以上三個問題，我們進行情景再現，用Demo來演示一個專案在Git上的正確管理步驟。

·       初始匯入現在我們拿到了版本A的程式碼，將其提交到遠端Git倉庫上大家應該是沒有問題的，從Android Studio的版本節點樹可以看到，可以看到我們有了本地主分支master和遠端主分支origin/master，HEAD指向的是本地的master分支。

·       建立開發分支現在版本A已經發布，我們要進行版本B的開發了，這裡最關鍵的是我們不可以在master主支上直接進行開發，master主支應當作為生產環境上的正式版本的釋出分支，該分支的每個版本最好是有效的、乾淨的，原則上嚴禁對釋出版本直接進行修改。所以我們需要一個開發分支，稱為developer分支，這個分支用來專門開發新版本。現在我們從版本A創建出一個developer分支，在工作空間根目錄cmd下執行：

·       git branch developer master

即從master建立developer的意思，版本樹如下：

可以看到我們現在有了本地的developer分支，我們還要把該分支上傳到遠端倉庫，執行
git push origin developer:developer
執行結果如下，意思是將本地的developer分支上傳到遠端origin/developer，如果遠端不存在'origin/developer'分支，則新建之

為了便於觀察，我在developer分支上提交了一個節點，現在觀察版本樹

·       儲存正在寫的程式碼現在我們正在developer分支上改動程式碼，但是master分支出現了一個緊急的bug，我們應該執行gitstash，作用是暫存我們在developer上做的沒有提交的修改，然後我們執行
git branch bugbranch master
從master分支檢出一個新的bug分支bugbranch，而不是直接切換到master分支上進行修改。現在觀察版本樹，可以看到從master分支分離出了bugbranch分支，現在HEAD指向的就是該分支。

·       修復bug現在我們在bugbranch分支上修復了bug，並且測試通過了，那麼接下來我們需要把修復後的程式碼commit一次，做一個節點儲存記錄一下，現在觀察版本樹

·       合併bug分支在bugbranch分支上我們已經修復了bug，那麼我們需要將bugbranch分支上修復後的程式碼合併到master分支上去，做一個節點並且釋出新版本，先切換到master分支git checkout master，然後執行
git merge bugbranch
將bugbranch分支合併到master分支上，現在觀察版本樹

可以看到現在master和bugbranch分支上的程式碼已經合併成功一致，接下來還要將最新的程式碼push到遠端分支上去，執行git push originmaster:master，觀察下邊的版本樹可以看到，現在本地和遠端分支上的程式碼都已經更新完成，我們可以釋出新版本了

·       合併修復的bug到開發分支到了這裡bugbranch分支的任務就完成了，我個人認為已經沒有保留的必要了，因為本次修改的過程已經記錄到了master的節點上，如果以後出了問題，再從當前節點重新檢出一個分支就好，執行
git branch -d bugbranch

刪除bugbranch分支，現在bug已經修復並且釋出，我們需要回到正常的開發分支上去繼續開發新的功能，執行git checkout developer先切換到developer分支，然後執行
git stash pop
取出我們當時在developer分支上stash的未提交的程式碼，至於我們在master分支上修復的bug怎麼更新到developer分支上，分兩種情況處理：

1、如果該bug影響到新模組的開發，那就手動更新修復部分的程式碼，到時候新模組開發完成之後我們將developer分支合併回master的時候就會產生衝突，解決掉就好；

2、如果該bug對新模組的開發沒影響，那就不用做處理，到時候將developer分支合併回master之後修復後的程式碼自然就更新了。

·       合併開發分支到master現在我們developer分支上的新功能寫完並且測試通過了，我們需要先將developer分支上的程式碼都提交到遠端'developer'分支上，我們釋出新版本的時候需要先將developer分支的程式碼合併到master分支上去，執行git checkout master切換到master分支，執行get merge developer來進行合併，這個時候可能會產生衝突，對照解決即可。

下面是developer分支向master合併的時候產生了衝突，解決掉合併後的版本樹

接下來我們需要先將本地的master分支提交更新到遠端，可以發現雖然developer分支雖然成功合併到master上了，但是因為產生了衝突，developer分支比master分支落後兩個節點（分別是1.解決merge衝突的節點 2.當初修改的bug節點），也就意味著程式碼有了差別，如下圖所示：

如果出現這種情況，需要再次執行get merge developer，再合併一次，這次衝突已經被解決了，直接合併成功，接下來我們直接將本地的developer分支程式碼提交到遠端origin/developer分支即可，最終的程式碼樹如下：

六、後言

在快速迭代開發中，經常會有需要緊急處理生產環境版本bug的時候，按照這樣的分支管理操作，可以做到快速的拿到每一個釋出版的程式碼；在開發新模組、修復舊bug、恢復舊版本的時候不互相汙染程式碼；乾淨、清楚的記錄每次更新、修復、迭代的內容。