Git – Fast Forward 和 no fast foward

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」整個提交鏈的完整性。