如何規范的合並分支

通常在分支合並的過程中要做到兩點：

• 產生有效的合並結果
• 提交日志記錄具備可讀性

如果僅僅保證合並結果的正確性，卻忽略日志記錄的可讀性，將產生不受約束的合並日志，導致代碼倉庫不可維護，影響項目后期開發。這里我們圍繞日志記錄的可讀性（第二點），來探討合並分支的各種方法，並歸納出不同場景下的最佳實踐。

場景一：功能分支開發完畢，並入主分支

$ git checkout master
Switched to branch 'master'
$ git merge feature
Fast-forward

最簡單的場景，合並分支的默認實踐

場景二：功能分支開發中途獲取主分支更新，在開發完畢后並入主分支

通過merge 獲取主分支更新

這里有一個fast-forward的設置，默認進行快速合並，對分支進行共線性整合。當然我們也可以選擇非快進模式，參數--no-ff用來保留分支信息。

• default fast-forward

$ git checkout feature
Switched to branch 'feature'
$ git merge master
Fast-forward
$ git checkout master
Switched to branch 'master'
$ git merge feature
Fast-forward

• non fast-forward

$ git checkout feature
Switched to branch 'feature'
$ git merge --no-ff master
Non fast-forward
$ git checkout master
Switched to branch 'master'
$ git merge --no-ff feature
Non fast-forward

通過rebase 獲取主分支更新(最佳實踐)

• default fast-forward

$ git rebase --onto master
$ git checkout master
Switched to branch 'master'
$ git merge feature
Fast-forward

• non fast-forward

$ git rebase --onto master
$ git checkout master
Switched to branch 'master'
$ git merge --no-ff feature
Non fast-forward

通過rebase重新整理功能分支，--no-ff保留分支信息，應為最佳實踐

場景三：功能分支開發完畢，並入生產分支，在開發完畢后並入主分支

• default fast-forward

$ git checkout -b dev
Switched to a new branch 'dev'
$ git merge feature
Fast-forward
$ git checkout master
Switched to branch 'master'
$ git merge dev
Fast-forward

• non fast-forward

$ git checkout -b dev
Switched to a new branch 'dev'
$ git merge --no-ff feature
Non fast-forward
$ git checkout master
Switched to branch 'master'
$ git merge --no-ff dev
Non fast-forward

多級分支進行合並，--no-ff保留分支信息，應為最佳實踐

場景四：如何保留臟代碼

我們要時刻保證日志記錄的可讀性，關於臟代碼的存儲和應用，也需要進行規范。

1、git提供了stash命令，為每個repository提供了一個存儲棧，用來臨時存儲未完成的修改，並且可以pop於任意一條分支上。因為這是一個棧的存儲結構，所以我們只能依序存，依序取，如若需要將臟代碼永久留下並在必要時加以應用，我們可以采取后一種方案。

$ git stash
$ git stash pop

2、鑒於stash的局限性，我們可以再建立一條標記分支用來保存臟代碼，利用from即可將其再次運用於任意一條新分支上

$ git rebase --onto 'base' from 'start'