先說結論：若沒啥好奇心或 branch 的潔癖的話，可以跳過這篇。可能 99.9% 的情況，有沒有用 --no-ff 不會有實務上的差別吧？
stackoverflow 上有關於 git merge --no-ff 的說明， git merge 的時候，如果發現只需要移動目前 branch 的位置即可完成 merge，git 預設不會產生新的 merge commit，這稱為 “fast forward”。其中一個使用時機是用來 merge feature branch，這樣保證有保留 feature branch 的結構：
需要長久開發的功能，我會在 remote 開 feature branch。回來的時候 master 應該已有別人的 commits，所以我的使用情境大概不會用到。
另一方面， merge 開發中 branch 到 stable branch 的時候，我會想用 --no-ff。假設 master 是開發用的 branch，stable 是客戶用的 branch。工作流程如下：
- cherry-pick master 緊急的修改到 stable。
- 或是直接在 stable 修 bug。
- 偶而 merge stable 回 master，降低日後 merge 的複雜度。
- 短期內無緊急出新版壓力的時候，merge master 到 stable，避免兩者差異愈來愈大。
在這樣的工作流程下，需要 merge master 到 stable 的時候，作法如下：
git checkout master- (master)
git merge stable - (master)
git checkout stable - (stable)
git merge master
上述操作形成的圖如下：
如果最後一步改用 git merge master --no-ff，結果會變成：
C8 和 C9 的主要差別是 parent commits 不同：
C8~ = C8^ = C8^1 = C2C9~ = C9^ = C9^1 = C3
有 C9 的話，用 ~ 和 ^ 會比較好找 merge commit 之前同 branch 的 commits，還有結構上分得比較清楚。不過我還沒遇到一定要有 C9 的使用情境。
