Git merge是不是必須合併分支？能否合併兩個commit？

Question

git merge 合併操作，是不是必須合併分支尖端(tip of branch)，能否合併任意的兩個提交commit？
例如，存在分支hotfix和分支master，結構如下：

      /A+--+B+----+C   hotfix
     /

init---->D --->E --->F ---->G master

#問題1：
我想合併thotfix分支中途的某個提交，例如B到目前分支 master上。
可以嗎？
因為從指令的參數解釋來看，可以使用commit，而不是必須使用分支名 branchName。

問題2：
如果還存在一個分支topic(圖中沒畫出來)，當前分支是master，我希望合併hotfix和topic分支，但不合併到當前分支master，同時不切換分支，要求保持目前分支仍然是master，是否可以做到？
因為從指令的參數來看，可以接受多個 commits，manual中說，多個commit合併構成了一個章魚合併，我就在想多個commits合併，是不是必須合併到當前分支。於是就有了這個問題。

Answer 1

使用cherry-pick挑選你要的投稿

Answer 2

首先，你這張圖畫得貌似有點問題，看不出來這兩個 branch 是從 哪裡分離的。你應該使用 git cherry-pick 指令，而不是 merge。只能猜一下，是不是這樣？

   A - B - C           hotfix
  /
init - D - E - F - G   master

後面的回答都基於這個猜測。如果和你的不同，請評論指出。

問題一：簡單來說，最好用 cherry-pick。
首先你要知道，git merge 和 git cherry-pick 是不同的。 。如果你要在這裡用 git merge B，那就會得到這樣的結果：

     A  -  B  -  C   hotfix
    /       \
init-D-E-F-G-G'      master

但如果你是 git cherry-pick B，就會得到這樣的結果：

   A - B - C                hotfix
  /
init - D - E - F - G - B'   master

merge 有它的優點，因為每一次 merge 其實都是創造一個新的 "merge commit"，而且會 "保留歷史"，所以是一個 "non-destructive"（非破壞性）的過程。當然，cherry-pick 也有它的缺點，首先是創建一個新的 hash，這可能會導致多人協作的混亂。例如有人已經在 G 後面又加了 HJKL，那至少他還要 rebase 一下。另外，這個 B' 也不會像 merge 那樣保留自己的歷史紀錄。因此，確切的說，這個 B' 更像是一個 patch。 （請參考 git format-patch https://git-scm.com/docs/git-...

我個人比較喜歡 cherry-pick 和 rebase 這樣的指令，不太喜歡 merge，最主要是因為歷史線簡潔很多。雖然這兩個命令比 merge 破壞性稍強，但稍微熟悉一點兒 git，知道每一步在做什麼以及可能造成什麼影響就好。

---

問題二：
感覺是不行的。 merge 不像 rebase 有類似 --onto 這樣的參數。還是切換過去再 merge 吧。

你後面說到章魚合併，你說的是 --strategy=octopus 麼？不太確定這個 strategy 和你要問的有什麼關聯。 。因為多個 branch 的 merge 預設 strategy 就是 octopus。 。不用去專門設定。 。 。順便，對於單一 HEAD 的 merge，預設 strategy 是 recursive。

對於你說的多個 commits 合併，請詳細描述一下你的需求。或是畫個圖補充一下