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
I want to merge a submission halfway through the thotfix branch, such as b to the current branch master.
Because judging from the parameter interpretation of the command, you can use commit instead of having to use the branchName.
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 use
git cherry-pickCommand, not
merge. 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 use
First of all, you have to know,
git merge <hash>And
git cherry-pick <hash>It’s different. . If you want to use it here
git merge B, that will get the result:
A - B - C hotfix / \ init-D-E-F-G-G' master
But if you are
git 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 time
mergeIn 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 it
rebaseExcuse me. In addition, this b’ will not look like
mergeThat way, keep your own history. Therefore, to be exact, this b’ is more like a patch. (Please refer to
git format-patchhttps://git-scm.com/docs/git- …
Personally, I prefer it
rebaseI don’t like such orders very much.
mergeThe main reason is that the historical line is much simpler. Although these two commands are compared
mergeIt is slightly destructive, but a little bit familiar with git, knowing what each step is doing and what impact it may have.
The feeling is not good.
rebaseThat is similar to
--ontoSuch parameters. Or switch to the past
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 many
mergeThe default strategy is octopus. . There is no need to set it up specially. . . By the way, for a single HEAD
merge, 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