標籤：

Git 最佳實踐：分支管理

07-17
本文作者： 伯樂在線 - legendtkl 。未經作者許可，禁止轉載！歡迎加入伯樂在線 專欄作者。1.引言

git 和 svn 的一個顯著區別就是提供更豐富的分支特性，我們今天就要說一下如何管理這些分支。關於 git 的分支管理，Vincent Driessen 有一篇文章說的非常好，地址在參考[1]。我這裡主要就是參考他的文章。

2. 總覽

git 的分支整體預覽圖如下。

從上圖可以看到主要包含下面幾個分支：

  • master: 主分支，主要用來版本發布。
  • develop：日常開發分支，該分支正常保存了開發的最新代碼。
  • feature：具體的功能開發分支，只與 develop 分支交互。
  • release：release 分支可以認為是 master 分支的未測試版。比如說某一期的功能全部開發完成，那麼就將 develop 分支合併到 release 分支，測試沒有問題並且到了發布日期就合併到 master 分支，進行發布。
  • hotfix：線上 bug 修復分支。

    • 除此之後還可以有 fast-track 等分支。

    3. 主分支

    主分支包括 master 分支和 develop 分支。master 分支用來發布，HEAD 就是當前線上的運行代碼。develop 分支就是我們的日常開發。使用這兩個分支就具有了最簡單的開發模式：develop 分支用來開發功能，開發完成並且測試沒有問題則將 develop 分支的代碼合併到 master 分支並發布。

    這引入了幾個問題：

    1. develop 分支只有發布完了才能進行下一個版本開發，開發會比較緩慢。
    2. 線上代碼出現 bug 如何進行 bug 修復。

    帶著這兩個問題往下看。

    4. 輔助分支

    主要介紹的輔助分支如下：

  • feature 分支
  • release 分支
  • hotfix 分支

    • 通過這些分支，我們可以做到：團隊成員之間並行開發，feature track 更加容易，開發和發布並行以及線上問題修復。

    4.1 Feature 分支

    feature 分支用來開發具體的功能，一般 fork 自 develop 分支，最終可能會合併到 develop 分支。比如我們要在下一個版本增加功能1、功能2、功能3。那麼我們就可以起三個feature 分支：feature1，feature2，feature3。（feature 分支命名最好能夠自解釋，這並不是一種好的命名。）隨著我們開發，功能1和功能2都被完成了，而功能3因為某些原因完成不了，那麼最終 feature1 和 feature2 分支將被合併到 develop 分支，而 feature3 分支將被幹掉。

    我們來看幾個相關的命令。

    從 develop 分支建一個 feature 分支，並切換到 feature 分支

    12 $ git checkout -b myfeature developSwitched to a new branch "myfeature"
    合併feature 分支到 develop

    12345678 $ git checkout developSwitched to branch "develop"$ git merge --no-ff myfeatureUpdating ea1b82a..05e9557(Summary of changes)$ git branch -d myfeatureDeleted branch myfeature$ git push origin develop

    上面我們 merge 分支的時候使用了參數 --no-ff，ff 是fast-forward 的意思，--no-ff就是禁用fast-forward。關於這兩種模式的區別如下圖。（可以使用 sourceTree 或者命令git log --graph查看。）

    看了上面的圖，那麼使用非fast-forward模式來 merge 的好處就不言而喻了：我們知道哪些 commit 是某些 feature 相關的。雖然 git merge 的時候會自動判斷是否使用fast-farward模式，但是有時候為了更明確，我們還是要加參數--no-ff或者--ff。

    4.2 Release 分支

    release 分支在我看來是 pre-master。release 分支從 develop 分支 fork 出來，最終會合併到 develop 分支和 master 分支。合併到 master 分支上就是可以發布的代碼了。有人可能會問那為什麼合併回 develop 分支呢？很簡單，有了 release 分支，那麼相關的代碼修復就只會在 release 分支上改動了，最後必然要合併到 develop 分支。下面細說。

    我們最初所有的開發工作都在 develop 分支上，當我們這一期的功能開發完畢的時候，我們基於 develop 分支開一個新的 release 分支。這個時候我們就可以對 release 分支做統一的測試了，另外做一些發布準備工作：比如版本號之類的。

    如果測試工作或者發布準備工作和具體的開發工作由不同人來做，比如國內的 RD 和 QA，這個 RD 就可以繼續基於 develop 分支繼續開發了。再或者說公司對於發布有嚴格的時間控制，開發工作提前並且完美的完成了，這個時候我們就可以在 develop 分支上繼續我們下一期的開發了。同時如果測試有問題的話，我們將直接在 release 分支上修改，然後將修改合併到 develop 分支上。

    待所有的測試和準備工作做完之後，我們就可以將 release 分支合併到 master 分支上，並進行發布了。

    一些相關命令如下。

    新建 release 分支

    1234567 $ git checkout -b release-1.2 developSwitched to a new branch "release-1.2"$ ./bump-version.sh 1.2File modified successfully, version bumped to 1.2.$ git commit -a -m "Bumped version number to 1.2"[release-1.2 74d9424] Bumped version number to 1.21 files changed, 1 insertions(+), 1 deletions(-)
    release 分支合併到 master 分支

    123456 $ git checkout masterSwitched to branch "master"$ git merge --no-ff release-1.2Merge made by recursive.(Summary of changes)$ git tag -a 1.2
    release 分支合併到 develop 分支

    12345 $ git checkout developSwitched to branch "develop"$ git merge --no-ff release-1.2Merge made by recursive.(Summary of changes)
    最後，刪除 release 分支

    12 $ git branch -d release-1.2Deleted branch release-1.2 (was ff452fe).

    4.3 Hotfix 分支

    顧名思義，hotfix 分支用來修複線上 bug。當線上代碼出現 bug 時，我們基於 master 分支開一個 hotfix 分支，修復 bug 之後再將 hotfix 分支合併到 master 分支並進行發布，同時 develop 分支作為最新最全的代碼分支，hotfix 分支也需要合併到 develop 分支上去。仔細想一想，其實 hotfix 分支和 release 分支功能類似。hotfix 的好處是不打斷 develop 分支正常進行，同時對於現實代碼的修復貌似也沒有更好的方法了（總不能直接修改 master 代碼吧:D）。

    一些相關的命令。

    新建 hotfix 分支

    1234567 $ git checkout -b hotfix-1.2.1 masterSwitched to a new branch "hotfix-1.2.1"$ ./bump-version.sh 1.2.1Files modified successfully, version bumped to 1.2.1.$ git commit -a -m "Bumped version number to 1.2.1"[hotfix-1.2.1 41e61bb] Bumped version number to 1.2.11 files changed, 1 insertions(+), 1 deletions(-)
    Fix bug

    123 $ git commit -m "Fixed severe production problem"[hotfix-1.2.1 abbe5d6] Fixed severe production problem5 files changed, 32 insertions(+), 17 deletions(-)
    buf fix 之後，hotfix 合併到 master

    123456 $ git checkout masterSwitched to branch "master"$ git merge --no-ff hotfix-1.2.1Merge made by recursive.(Summary of changes)$ git tag -a 1.2.1
    hotfix 合併到 develop 分支

    12345 $ git checkout developSwitched to branch "develop"$ git merge --no-ff hotfix-1.2.1Merge made by recursive.(Summary of changes)
    刪除 hotfix 分支

    12 $ git branch -d hotfix-1.2.1Deleted branch hotfix-1.2.1 (was abbe5d6).

    參考

    1. A successful Git branching model

    推薦閱讀：

    TAG:管理 | 實踐 | 最佳實踐 |