A merge conflict feels alarming the first time, but it's one of the most honest things git does. It's git stopping and saying "two people changed the same spot, I can't guess what you wanted." You're the one who gets to decide, and that's a good position to be in.
About 2 min of reading
Before this new lesson, one small question about the lesson you just finished. Recall it, do not look it up.
A merge conflict felt like the whole thing breaking the first time, but it was just two of us editing the same line. Let me force that exact situation, watch git stop and leave the markers, then resolve it so I can see that it is nothing to be alarmed about.
Start with a file both of us will edit, here that is two of you, one working copy and one branch. I make one commit so there is a clean shared starting line that later both branches will change.
Before you run it, say out loud what it will print. Then open the answer.
On the feature branch, change that one line to a different color. I stay on my new branch while main moves on too, which is what makes the two lines of history actually disagree on the same spot.
Before you run it, say out loud what it will print. Then open the answer.
Go back to main and change that same line to something else, then try to bring the branch in. Because both sides edited the identical line, git cannot pick a winner on its own. It stops and leaves the markers in the file, that is the honest part, git refusing to guess.
Before you run it, say out loud what it will print. Then open the answer.
Read the markers instead of panicking at them. Everything above ======= is my side (main), everything below is theirs (feature/login), and the split line is what they wrote. Two colors, one line, I keep whichever is right or combine them, then delete every marker.
Before you run it, say out loud what it will print. Then open the answer.
Write the version I actually want, stage it, and commit to close the merge. The conflict disappears from history the moment I commit, and this becomes just another entry in the timeline.
Before you run it, say out loud what it will print. Then open the answer.
Before you write anything, put these lines back in the right order. Click a line to move it up one step. This support step is easier than writing code from scratch, and it is here to make the last example stick.
A conflict appears when the same stretch of a file is changed by two people at once. They're completely normal, every collaborator hits them, the experienced ones included, and they always have a clean resolution.
Read both sides. Keep whichever is correct, or stitch them together into a version that makes sense. Delete the markers, commit, and the conflict is gone from the history.
Both you and a teammate changed line 10.
git shows you exactly where you disagree:<<<<<<< HEAD
button_color = "blue"
=======
button_color = "red"
>>>>>>> feature/loginThe markers tell the story: everything above ======= is what's on your current branch, everything below is what your teammate wrote. Read both sides, pick the one that's right (or keep both), delete the markers, and commit to resolve it.
<<<<<<< HEAD
const price = 10
=======
const price = 12
>>>>>>> featureNot every conflict looks the same. Sometimes two people edit different lines that happen to sit right next to each other. Git still flags them as adjacent changes. GitHub shows both versions with the markers, so you edit the file to keep the lines that belong together, drop the markers, and save.
Open the PR -> "Resolve conflict"
Edit the lines to the shape you want
Delete <<<< ======= >>>>>
Commit mergeGitHub ships a built-in editor for exactly this. You can pick each side with a button, let it strip the markers for you, and commit from there. It's much easier than poking at conflict markers in a plain text editor at 11 pm.
Each one is defined here on this site. Open the entry for the full definition and the other words it points at.