0

I wanted to comment out <AppNavigator /> and un-comment <OnboardingNavigator />. Can someone explain why this is a merge conflict and how to resolve it? This is when I'm trying to do a PR on Bitbucket.

enter image description here

SwissCodeMen
  • 4,222
  • 8
  • 24
  • 34
gkeenley
  • 6,088
  • 8
  • 54
  • 129
  • 1
    Well, it appears one branch commented out one line and the other branch commented out the other line. Since they were so close, git is programmed to view this as a conflict, because of the potential of picking the wrong thing. – Lasse V. Karlsen Jan 13 '22 at 20:21
  • I'm trying to merge a branch into `main`. So `main` is `destination` here. All I want is to have `` un-commented, whether the commented-out `` is there or not. Any suggestions on how to achieve this? – gkeenley Jan 13 '22 at 20:23
  • 1
    You can force a decision by using `-X ours` or `-X theirs` to choose which branch should 'win'. – match Jan 13 '22 at 20:30
  • @match Where do I do that? Can I do it within the PR itself? – gkeenley Jan 13 '22 at 20:54
  • Is a conflict because you don't have a commit and this commit is changing the same line. Did you solve your problem? Are you able to fix it using the shell? – JRichardsz Jan 13 '22 at 22:35
  • @JRichardsz Can you explain more what you mean about the commits? I committed and pushed to a branch, and I'm trying to merge it into main. – gkeenley Jan 14 '22 at 03:49
  • Sure. One reason of conflict is that someone (maybe yourself) performed a commit to a file in the same line that you are try to perform a new commit. Did you solve your problem? If you are the only developer, it is easy to fix a conflict. – JRichardsz Jan 14 '22 at 05:12

1 Answers1

1

Merge conflicts—not just in Git, but in version control systems generally—involve three input files, not two.

There's some original version of the file:

la la la
if some thing {
   do action X
} else {
   do action Y
}
rawhide!

Then there's your version of this file:

la la la
if some thing {
   do action W, not X
} else {
   do action Y
}
rawhide!

Finally, there's their version of this same file:

la la la
if some thing {
   do action Z, not X, not W
} else {
   do action Y
}
rawhide!

Git is combining your change—which says to replace X with W—and their change, which says to replace X with Z. It's not possible to use both changes! Should we do W, or should we do Z? Git doesn't know the right answer.

Your job, as the human who understands what the code means—all Git knows is that there are text lines that have been changed here—is to figure out whether W or Z is correct. (Perhaps none of them are correct, not even X, although this is generally not a good situation during a merge: it means that all of the merge's inputs are bad! For such a case, you must use your own judgment—which you're already doing in order to select W vs Z.)

Read the code. Understand what's going on. Figure out which of the alternatives, if any, is the correct one. (If none is the correct one, figure out what is correct, or reject the merge request entirely.) Put the correct code into the file, and tell Git: I have put the correct code into the file; use my version. This resolves the merge conflict.

torek
  • 448,244
  • 59
  • 642
  • 775