Git 很是強大，在體驗過rebase的華麗之后，再次發現之前在TFS上遇到的問題一下都有解了。但也印證了Git深入並非易事。這篇就談下一個容易迷糊的概念：Fast forward。
Fast-Forward
當前分支合並到另一分支時，如果沒有分歧解決，就會直接移動文件指針。這個過程叫做fastforward。
舉例來說，開發一直在master分支進行，但忽然有一個新的想法，於是新建了一個develop的分支，並在其上進行一系列提交，完成時，回到 master分支，此時，master分支在創建develop分支之后並未產生任何新的commit。此時的合並就叫fast forward。
示例：
1. 新建一個work tree，在master中做幾次commit
2. 新建develop的branch，然后再做多次commits
此時的分支流圖如下(gitx)：
正常合並
(master)$ git merge develop
Updating 5999848..7355122
Fast-forward
c.txt | 1 +
d.txt | 1 +
2 files changed, 2 insertions(+), 0 deletions(-)
create mode 100644 c.txt
create mode 100644 d.txt
可以看出這是一次fast-forward式的合並，且合並完之后的視圖為扁平狀，看不出develop分支開發的任何信息。
使用–no-ff進行合並
—no-ff (no fast foward)，使得每一次的合並都創建一個新的commit記錄。即使這個commit只是fast-foward，用來避免丟失信息。
(master)$ git merge –no-ff develop
Merge made by recursive.
c.txt | 2 +-
d.txt | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
可以看出，使用no-ff后，會多生成一個commit 記錄，並強制保留develop分支的開發記錄（而fast-forward的話則是直接合並，看不出之前Branch的任何記錄）。這對於以后代碼進行分析特別有用，故有以下最佳實踐。
好的實踐
–no-ff，其作用是：要求git merge即使在fast forward條件下也要產生一個新的merge commit。此處，要求采用–no-ff的方式進行分支合並，其目的在於，希望保持原有“develop branches”整個提交鏈的完整性。Git – Fast Forward 和 no fast foward