I manually produced a merge conflict in my test repository. Here is the conflict:

<<<<<<< HEAD

Carry

=======

Mid

>>>>>>> 635e85d6e45907a6b1c63d934618040adcbb8474

The "635e85d6e45907a6b1c63d934618040adcbb8474" confuses me. Shouldn't this be the branch name instead

CodePudding user response：

635e85d6e45907a6b1c63d934618040adcbb8474 is the name of the head of a certain commit. Git gives you the possibility to "travel in time" back to the previous version of your code. The number signifies a specific commit.

You can find a list of commits by running git log and find the same number there.

git branch to see what branch you're on if your branch is, for example, called developer then you can run git checkout developer to get back to that branch.

the <<<<<<< and >>>>>> indicate that the same files have been changed from multiple sources, and its trying to merge, but it doesn't know which one to keep.

I highly suggest you refer to the documentation https://git-scm.com/doc

CodePudding user response：

Shouldn't this be the branch name instead?

It usually is, but not always:

• If you run git merge hash, Git has only the hash ID for the other commit, so that's what you get.
• If you run a git merge that performs a recursive merge—by this I mean a merge using the recursive strategy that actually winds up recursing, as opposed to most merges, which don't—the inner merge uses a raw hash ID, and this hash ID winds up in the merge base text.

The method by which Git puts in a branch name rather than a raw commit hash ID is a bit sneaky,¹ and re-creating a merge conflict with git checkout -m does not use it and hence uses the raw hash ID as well.

¹The merge code sets some magic environment variables that allow the low-level merge code to translate from hash ID to arbitrary name. These are not documented and are therefore subject to change, so don't use them even if you figure out what they are.