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

先說結論:若沒啥好奇心或 branch 的潔癖的話,可以跳過這篇。可能 99.9% 的情況,有沒有用 --no-ff 不會有實務上的差別吧?

stackoverflow 上有關於 git merge --no-ff 的說明, git merge 的時候,如果發現只需要移動目前 branch 的位置即可完成 merge,git 預設不會產生新的 merge commit,這稱為 “fast forward”。其中一個使用時機是用來 merge feature branch,這樣保證有保留 feature branch 的結構:

出處:http://stackoverflow.com/a/21717431/278456

需要長久開發的功能,我會在 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,結果會變成:

無 fast forward 的 merge

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

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

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

Show your support

Clapping shows how much you appreciated fcamel’s story.