You run git merge or git pull and it stops with
CONFLICT (content): Merge conflict in app.py and
Automatic merge failed; fix conflicts and then commit the result. Opening the
file shows it "corrupted" with strange lines: <<<<<<< HEAD, =======, and
>>>>>>> branch-name, with two versions of your code between them.
Two people (or two of your own branches) edited the same lines of the same file. Most common on a first team project: you pull main after a teammate's pull request merged, or you merge your feature branch after main moved ahead. Freshers often abandon the folder and re-clone at this point — losing work for no reason. Linked module: 0.2 (Git & GitHub as an engineer).
Git merges by combining line changes from both sides. When the two sides changed
the same lines differently, Git refuses to guess and hands the decision to you.
The markers are a report, not damage: the block between <<<<<<< HEAD and
======= is your current branch's version; the block between ======= and
>>>>>>> is the incoming branch's version. The repository is paused mid-merge:
git status lists the files under "Unmerged paths" with "both modified". Only
those listed files need attention — everything else merged cleanly. Both full
versions still exist as commits, so nothing can be lost by resolving.
Calm, four steps, per conflicted file. (1) Open the file and read both blocks.
(2) Edit to the single version that should survive — one side, the other, or a
combination. (3) Delete all three marker lines. (4) git add <file>, and when
git status shows no unmerged paths, git commit to complete the merge. If the
conflict arrived mid-pull and you want to regroup, git merge --abort returns
the folder to its pre-merge state — a clean undo, no re-clone needed. Verify the
result: git grep "<<<<<<<" must return nothing before you push.
Pull main into your branch often — small, frequent merges make small, rare conflicts. Keep branches short-lived: a branch that lives for weeks collides with everything. Split work so two people rarely edit the same file in the same sprint, and say so in standup when you must. Commit small units with clear messages, so when a conflict does come, both sides are easy to read.
Q: "You pull and get a merge conflict in a file you both edited. Walk me through
what Git is doing and what you do next." Strong answer: state that Git stops when
both sides changed the same lines, decode the three markers and which side is
which, give the four-step resolution ending in add and commit, and mention
git merge --abort as the safe exit — plus the prevention line about short-lived
branches, which shows team experience.