Sooner or later two branches change the same line. You change your tagline on main to “Front-end developer in Lagos.” while your tagline branch, started earlier, rewrote the same line to “Front-end developer who loves accessible UI.” Git can’t know which is right, so it stops and asks. That’s all a merge conflict is: a question. I’ve helped hundreds of people through their first one, and the panic always comes from the unfamiliar markers, never from the actual problem.
git switch main\ngit merge taglineAuto-merging index.html\nCONFLICT (content): Merge conflict in index.html\nAutomatic merge failed; fix conflicts and then commit the result.You’re now in the middle of a merge. Any files that merged cleanly are already staged. Run git status to see the rest:
On branch main\nYou have unmerged paths.\n (fix conflicts and run "git commit")\n (use "git merge --abort" to abort the merge)\n\nUnmerged paths:\n (use "git add <file>..." to mark resolution)\n\tboth modified: index.html\n\nno changes added to commit (use "git add" and/or "git commit -a")Read that output; it’s the whole procedure. Fix the conflicts, mark each file resolved with git add, then git commit. Or abort.
Open index.html. Git has written both versions into the file, fenced by markers:
<h1>Maya Okafor</h1>\n<<<<<<< HEAD\n <p>Front-end developer in Lagos.</p>\n=======\n <p>Front-end developer who loves accessible UI.</p>\n>>>>>>> taglineHEAD down to =======, is your side: the branch you’re on, here main.======= down to the closing marker labelled tagline, is their side: the branch you’re merging in.Everything outside the markers merged without trouble. A file can contain several of these blocks, so search the file for the opening marker (seven less-than signs) until there are none left.
\n1. Decide what the result should be. Not “which side wins” by reflex; what should the page actually say? Often it’s a combination. Here, both facts are good:
\n <h1>Maya Okafor</h1>\n <p>Front-end developer in Lagos who loves accessible UI.</p>2. Remove every marker. The three marker lines must go. Git doesn’t read the file to check; it’s your job.
\n3. Check the result. Open the page in a browser, run your tests (npm test once the portfolio has them), and run:
git diff --checkIt warns about any leftover conflict markers. Five seconds well spent.
\n4. Mark it resolved and finish.
\ngit add index.html\ngit status # \"All conflicts fixed but you are still merging.\"\ngit commit # editor opens with \"Merge branch 'tagline'\"; save and closegit merge --continue does the same as that final git commit. The merge commit now has two parents, like any other.
If you know one side should win for a whole file, skip the editing: git restore --ours index.html keeps your branch’s version and git restore --theirs index.html keeps the incoming one. Then git add it as usual.
If a conflict is bigger than you expected, or you merged the wrong branch, you can always retreat:
\ngit merge --abortYour branch, index and files go back to exactly how they were before git merge. Nothing is lost. It’s often smart to abort, update or tidy the branch, and try again with a clear head.
The same markers and the same fix-add-continue routine appear whenever Git combines two versions of a line: during a rebase, when you apply a stash, and when git pull merges someone else’s work into yours. Learn the routine once here and every later conflict in this course will look familiar. Only the command you use to continue or abort changes.
By default you see only the two sides. Ask Git to show the original lines too:
\ngit config --global merge.conflictStyle zdiff3Now each conflict has a third section between ||||||| and ======= showing the merge base. Seeing what the line was before either change usually makes the right answer obvious: you can see what each side meant to do, not only what it ended up with.
Editors help too. VS Code highlights each block with buttons such as Accept Current Change, Accept Incoming Change and Accept Both Changes, plus a three-way merge editor. Use them, but read the result; Accept Both often produces two <p> tags where you wanted one.
Merging is one way to combine histories. Next you’ll meet the other, rebasing, and the one rule that keeps it safe.
\n","toc":[{"id":"sec-1","text":"What Git tells you","level":2},{"id":"sec-2","text":"Reading the markers","level":2},{"id":"sec-3","text":"Resolving it, step by step","level":2},{"id":"sec-4","text":"Bailing out","level":2},{"id":"sec-5","text":"Making conflicts easier to read","level":2}],"takeaways":["A conflict means both branches changed the same lines since their merge base, so Git asks you to choose; nothing is lost or broken.","Between<<<<<<< and ======= is your current branch (HEAD); between ======= and >>>>>>> is the branch being merged in.","Resolve by editing the file into its final form, removing every marker, then git add the file and git commit.","git merge --abort puts everything back exactly as it was before the merge started.","Setting merge.conflictStyle to zdiff3 also shows the original lines, which makes most conflicts easy to judge."],"further":[{"title":"Basic Merge Conflicts (Pro Git)","url":"https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging#_basic_merge_conflicts"},{"title":"Resolving a merge conflict using the command line","url":"https://docs.github.com/en/pull-requests/how-tos/merge-and-close-pull-requests/resolving-a-merge-conflict-using-the-command-line"},{"title":"git merge, How conflicts are presented","url":"https://git-scm.com/docs/git-merge#_how_conflicts_are_presented"}],"quiz":[{"q":"You’re on main and ran git merge tagline. In index.html you see:
<<<<<<< HEAD\n<p>Front-end developer in Lagos.</p>\n=======\n<p>Front-end developer who loves accessible UI.</p>\n>>>>>>> taglineWhich line came from main?
Front-end developer in Lagos., because the top half is HEAD, your current branch.","why":"Correct. You’re on main, so HEAD is main. The bottom half, labelled tagline, is what’s being merged in."},{"text":"Neither; both lines are Git’s suggestions for a combined version.","why":"Git doesn’t invent text. Each half is exactly what one branch contains."}],"answer":1},{"q":"You’ve edited index.html so it reads the way you want and every marker is gone. git status still lists it under “Unmerged paths”. What’s the next step?
git merge tagline again so Git notices the fix.","why":"A merge is already in progress. Starting another one fails; Git is waiting for you to mark files as resolved."},{"text":"Run git commit -a --no-verify.","why":"--no-verify skips hooks and has nothing to do with conflicts. Stage the file and commit normally."},{"text":"Run git add index.html to mark it resolved, then git commit.","why":"Correct. Staging tells Git the conflict is settled. When no unmerged paths remain, git commit creates the merge commit."},{"text":"Delete index.html and run git restore index.html.","why":"That throws away the resolution you just wrote. There’s no reason to delete anything."}],"answer":2},{"q":"Halfway through a messy conflict you realise you merged the wrong branch. How do you get back to exactly where you were before the merge?
","options":[{"text":"git merge --abort","why":"Correct. While a merge is in progress, this restores the branch, the index and your files to their state before git merge."},{"text":"git restore .","why":"That discards working-tree changes but leaves Git in the middle of a merge, with the merge state still active."},{"text":"git branch -D main","why":"Deleting the branch you’re on isn’t allowed, and it wouldn’t undo anything."},{"text":"Close the terminal; unfinished merges are cancelled automatically.","why":"The merge state is stored in .git, not in your terminal session. It’s still there when you reopen it."}],"answer":0},{"q":"Your branch has merged and pushed, and a teammate finds ======= printed on the live home page. Which habit would have caught this before committing?
git log --graph after every merge.","why":"The graph shows commit structure, not file contents, so leftover markers wouldn’t appear."},{"text":"Always resolving with git merge --abort.","why":"Aborting cancels the merge instead of resolving it, so the work never lands."},{"text":"Using git commit -m instead of the editor.","why":"The message source has nothing to do with markers inside your files."},{"text":"Running git diff --check (and opening the page) before git add.","why":"Correct. git diff --check warns about leftover conflict markers, and actually viewing the result catches the rest."}],"answer":3}],"exercise":{"kind":"order","items":["merge","status","open","edit","check","add","commit"],"title":"Resolve the tagline conflict","prompt":"You’re on main and want the tagline branch merged in. Put the steps in the order you’d run them to get from the conflict to a finished merge commit.
git status tells you which files need you.","You fix the file before you check it, and you check it before you tell Git it’s resolved.","The merge commit is always the very last step."],"explanation":"The merge stops at the conflict; git status lists the unmerged files. You open each one, edit it into the final text and delete every marker, then check the result (git diff --check, view the page, run the tests). Only then does git add mark it resolved, and git commit (or git merge --continue) records the merge commit. If anything goes wrong before that last step, git merge --abort returns you to where you started.
git merge tagline and see CONFLICT (content): Merge conflict in index.html.","status":"Run git status to list the unmerged paths.","open":"Open index.html and find the <<<<<<< block.","edit":"Write the final tagline and delete the three marker lines.","check":"Run git diff --check and view the page in a browser.","add":"Run git add index.html to mark the conflict resolved.","commit":"Run git commit to record the merge commit."}},"words":741,"readMinutes":4}