Does Git merge have to merge branches? Can I merge two commits?

Question

Git merge merge operation, is it necessary to merge the tip of branch? Can any two commits be merged?
For example, there is branch hotfix and branch master, the structure is as follows:

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

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

Question 1:
I want to merge a commit in the middle of the thotfix branch, such as B, to the current branch master.
May I?
Because judging from the parameter explanation of the command, commit can be used instead of the branch name branchName.

Question 2:
If there is still a branch topic (not shown in the picture), and the current branch is master, I hope to merge the hotfix and topic branches, but not merge them into the current branch master, and do not switch branches at the same time. Requirements Is it possible to keep the current branch still master?
Because judging from the parameters of the command, multiple commits can be accepted. The manual says that the merger of multiple commits constitutes an octopus merge. I was wondering whether the merger of multiple commits must be merged into the current branch. So there is this problem.

Answer 1

Use cherry-pick to pick the submissions you want

Answer 2

First of all, there seems to be something wrong with your picture. You can’t tell where the two branches are separated. You should use the git cherry-pick command instead of merge. I can only guess, is that so?

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

The following answers are all based on this guess. If it's different from yours, please comment.

Question 1: To put it simply, it is best to use cherry-pick.
First of all, you need to know that git merge <hash> and git cherry-pick <hash> are different. . If you were to use git merge B here, you would get something like this:

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

But if you were git cherry-pick B, you would get this result:

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

merge has its advantages, because every time merge actually creates a new "merge commit" and "preserves history", so it is a "non-destructive" process. Of course, cherry-pick also has its drawbacks, the first being the creation of a new hash, which may lead to confusion in multi-person collaboration. For example, if someone has added HJKL after G, then at least he needs to rebase. In addition, this B' will not retain its own history like merge. So, to be precise, this B' is more like a patch. (Please refer to git format-patch https://git-scm.com/docs/git-...

I personally prefer commands like cherry-pick and rebase, but I don’t like merge very much, mainly because the history line is much simpler. Although these two commands are slightly more destructive than merge, it is good to be a little familiar with git and know what each step is doing and what impact it may have.

---

Question 2:
It feels like it’s not possible. merge does not have parameters like --onto like rebase. It’s better to switch over and merge.

When you mentioned the octopus merger later, did you mean --strategy=octopus? Not sure what this strategy has to do with what you're asking about. . Because the default strategy of merge for multiple branch is octopus. . No need to set it up specifically. . . By the way, for a single HEAD's merge, the default strategy is recursive.

For the merging of multiple commits you mentioned, please describe your needs in detail. Or draw a picture to supplement it