Does Git merge have to merge branches? Can we merge the two commit?

  git, question

Is it necessary to merge the tip of branch for the git merge merge operation, and can any two commit commits be merged?
For example, there are branch hotfix and branch master with the following structure:

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

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

Question 1:
I want to merge a submission halfway through the thotfix branch, such as b to the current branch master.
OK?
Because judging from the parameter interpretation of the command, you can use commit instead of having to use the branchName.

Question 2:
If there is still a branch topic (not shown in the figure), the current branch is master, I want to merge the hotfix and topic branches, but not to the current branch master, at the same time do not switch branches, require to keep the current branch is master, is it possible?
According to the parameters of the command, multiple COMMITTS can be accepted. According to manual, multiple COMMITTS merge constitutes an octopus merge. I wonder if multiple COMMITTS merge must be merged into the current branch. So there is this problem.

First of all, there seems to be something wrong with your picture. You can’t see where the two branch are separated. You should usegit cherry-pickCommand, notmerge. Can only guess, isn’t it?

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

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

Question 1: Simply put, it is best to usecherry-pick.
First of all, you have to know,git merge <hash>Andgit cherry-pick <hash>It’s different. . If you want to use it heregit merge B, that will get the result:

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

But if you aregit cherry-pick B, you will get the result:

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

mergeIt has its advantages because every timemergeIn fact, they all create a new “merge committee” and will “preserve history”, so it is a “non-destructive” process. Of course,cherry-pickThere are also its disadvantages. First, create a new hash, which may lead to chaos in the cooperation of many people. For example, someone has added HJKL after G, at least he still needs itrebaseExcuse me. In addition, this b’ will not look likemergeThat way, keep your own history. Therefore, to be exact, this b’ is more like a patch. (Please refer togit format-patch https://git-scm.com/docs/git- …

Personally, I prefer itcherry-pickAndrebaseI don’t like such orders very much.mergeThe main reason is that the historical line is much simpler. Although these two commands are comparedmergeIt is slightly destructive, but a little bit familiar with git, knowing what each step is doing and what impact it may have.


Question 2:
The feeling is not good.mergeunlikerebaseThat is similar to--ontoSuch parameters. Or switch to the pastmergeRight.

When you talk about octopus merger later, what you are saying is--strategy=octopus? I’m not sure if this strategy has anything to do with what you want to ask. . Because manybranchThemergeThe default strategy is octopus. . There is no need to set it up specially. . . By the way, for a single HEADmerge, the default strategy is recursive.

Please describe your requirements in detail for the merger of multiple commits you mentioned. Or draw a picture to add