（日本語はまだ、中国語ですみません 
）
台湾人の vc7 です。
在一般使用 Git 的開發日常中， branch 的新增和 merge 是很常見的事情。進行 merge 的時候，git 預設會以 fast-forward 的模式進行。
那什麼是 fast-forward merge 呢？和 no fast-forward 的 merge 有什麼差別？
Fast-Forward Merge 是什麼
當你目前的位置 (HEAD) 是某個要被 merge branch 上的 commit 的 root commit ，在沒有任何新的 commit 的情形下，要 merge 回來的時候，就會觸發 fast-forward 。
由於在原本的分支上沒有新的變更紀錄需要被 merged ，預設就會觸發 fast-forward merge ，就會直接把這個 commit HEAD 移動到要被 merge 的 commit 的位置，也不會新增一個 merge commit 。
前置作業
首先我們要先準備一系列含有 branch 的 commit ，長得如下圖
說明：
- HEAD - 當前所在位置，指標位置指向 master
- 藍色標籤 - branch 指標所指的 commit 位置
- 灰色底的文字 - commit messages
建立資料夾並初始化 git repo
打開終端機之後，移動到你想要的資料夾
mkdir git-ff-demo
cd git-ff-demo
git init
做幾個 commit 、建立 branch 後，再回到 master 上
初始化 git repository 之後，預設就會在 master 上。為了降低複雜度，這個範例在 commit 時會用到另外一個 flag - —-allow-empty ，可以讓你不用變更資料夾的情形下就可以執行 commit 。
git commit —-allow-empty -m “Initial Commit”
git commit —-allow-empty -m “a”
建立兩個 commit 之後，現在來建立如圖中的 b-01 分支
git checkout -b b-01
接著在 b-01 上再繼續多 commit 兩個變更
git commit —-allow-empty -m “b”
git commit —-allow-empty -m “c”
最後 checkout 回到 master ，準備把 b-01 merge 到 master 上：
git checkout master
這樣子就完成事前準備了，如果在 SourceTree 裡面看就會長這個樣子：
進行 Merge
預設的 merge
這時候執行
git merge b-01
這時候就會看到終端機有跳出回饋的訊息：
Updating 464aead..0169033
Fast-forward
提示我們他只是幫我們把目前 HEAD 所指到的 master 的指標位置換到 0169033
在 SourceTree 裡面看，就變成這樣了：
我的 branch 怎麼不見了（慌張）
因為 fast-forward 的關係，b-01 分支的特徵也就變得無法辨識了
Merge 時不要 fast-forward
在 merge 指令有個 —-no-ff flag，可以告訴 git 這次的 merge 無論如何都不要進行 fast-forward 。
開始前，可以在另外一個資料夾，在進行一次前置作業所做的事情，確認一下你的 git repo 是不是目前這個狀態：
執行指令
在 merge 的指令中，加上 —-no-ff 即可：
git merge —-no-ff b-01
（接著可能會跳出 vim 的編輯畫面，輸入 :wq 儲存並關閉就可以完成 merge commit）
這時候終端機就會跳出以下訊息，
Already up-to-date!
Merge made by the 'recursive' strategy.
來到 SourceTree 看，也就可以看到 b-01 branch 的分支特徵也保留下來：
除此之外，加上 --no-ff 之後就有加一次 merge 的 commit 記錄這一次的變更
加上 --no-ff 的優缺點
優點
在開發一個功能時，通常都會開一支新的分支，使用 --no-ff 可以讓成員在日後可以很清楚辨識不同的功能所包含的 commit 歷程有哪些
除此之外，GitHub merge pull request 的策略，也是使用 --no-ff ，也是讓開發者可以方便辨別。
缺點
假使這個 task 或是 bug-fix 只有一個 commit ，很容易造成一堆小耳朵的存在，如下圖：
對策
- 思考 task 規劃時的範圍是不是切太細？
- 或是在 git 流程中，啟用 hot-fix 之類的 branch 來負責 bug fix 的 commits ，零碎的 hot-fix 可以直接在這個 branch 上解決，比較龐大的 bug fix 再另外建立 branch 來負責
結語
我第一次執行 merge 的時候就有發現我的 branch 被 fast-forward merge 掉了，第一次看到真的有嚇到；到後來才知道原來這個叫做 fast-forward 。
幫團隊做 code review 後需要 merge 的時候，也都是使用這個方式保留 branch 的特徵（當時公司內還沒有採用 PR 的機制，所以都是手動來的）。
這篇的優缺點是我自己的想法和心得，如果有任何的想法和討論都可以在下面留言唷！
如果覺得這篇不錯，可以分享、或是點最最最上面的 Stock 按鈕儲存起來，謝謝您。
參考資料
本篇環境： Mac OS X 10.11, git 2.6.2, SourceTree 2.0.5.2