何時該用 git merge --no-ff？

fcamel

Follow

Feb 24, 2017 · 3 min read

先說結論：若沒啥好奇心或 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 的時候，作法如下：

1. git checkout master
2. (master)git merge stable
3. (master)git checkout stable
4. (stable)git merge master

上述操作形成的圖如下：

如果最後一步改用 git merge master --no-ff，結果會變成：

C8 和 C9 的主要差別是 parent commits 不同：

• C8~ = C8^ = C8^1 = C2
• C9~ = C9^ = C9^1 = C3

有 C9 的話，用 ~ 和 ^ 會比較好找 merge commit 之前同 branch 的 commits，還有結構上分得比較清楚。不過我還沒遇到一定要有 C9 的使用情境。