In Git, what do the <<<<<<<, =======, and >>>>>>> markers in a conflicted file mean?

## What a conflict actually is A merge in Git is a three-way operation: for each file it compares your side and the incoming side against their **common ancestor** (the merge base). Region by region, if only one side changed a region, Git takes that side without asking. If both sides changed the *same* region to *different* content, Git has no rule that decides which is correct, so it stops and hands the decision to you. That handover has two halves: markers written into the working-tree file, and an unmerged entry in the index. ## Anatomy of a conflict hunk Inside the file, each unresolvable region is wrapped in three marker lines, each seven characters long and starting at column one: - `<<<<<<<` followed by a label for **your** side. During a merge on a branch this is normally `HEAD`. - `=======` — the divider between the two candidate versions. - `>>>>>>>` followed by a label for the **incoming** side — a branch name, or a commit hash and subject. Everything between the opener and the divider is your version of that region; everything between the divider and the closer is theirs. A file can contain many such hunks, and the untouched parts of the file around them are already merged. Note that the markers are plain text: they are not a special file format, and nothing in Git prevents you from committing them by accident. ## The index during a conflict Normally each path sits at **stage 0** in the index — one resolved entry. A conflicted path instead occupies up to three stages: stage 1 is the merge-base version, stage 2 is *ours*, stage 3 is *theirs*. `git ls-files -u` prints them, and `git status` shows the path under *Unmerged paths*, usually as *both modified*. This is why a plain `git commit` refuses to run while a conflict is outstanding — the index is not in a committable shape. Staging the file with `git add` is what actually resolves it: the three stage entries collapse into a single stage-0 entry holding whatever bytes are in the working tree at that moment. Git does not inspect those bytes, which has a direct consequence covered below. ## Finishing the resolution The loop is always the same: 1. Open each conflicted file and edit the region to the content you intend to ship — which is frequently neither side verbatim but a combination. 2. Delete all three marker lines. 3. `git add <file>` for each resolved path. 4. `git commit` to complete a merge (the message is pre-filled from `.git/MERGE_MSG`), or `git rebase --continue` if the conflict arose during a rebase. `git status` remains the checklist: it keeps listing unmerged paths until every one is staged. ## What Git will not do for you Git never validates your resolution. If you stage a file that still contains `<<<<<<<`, Git commits it happily — this is one of the most common self-inflicted breakages, and it is why teams grep for marker lines before committing or wire that check into a client-side hook. Git also cannot see **semantic** conflicts: two sides can touch different regions, merge with zero markers, and still produce code that does not compile or behave correctly (one side renames a function, the other adds a call to the old name). Building and running the tests after resolving is part of the resolution, not an optional extra. ## Conflicts without markers Not every conflict produces markers. If one side deleted a file and the other modified it, `git status` reports *deleted by us* or *deleted by them*, and you resolve by choosing `git rm` or `git add`. Binary files cannot be merged line-wise, so Git leaves one version in place and asks you to pick a whole file. Both are still unmerged index entries, and both still finish with `git add`. ## Aborting instead Markers are not a trap you must fight through. Until you commit, the pre-merge state is recoverable — `git merge --abort` (or `git rebase --abort`) puts you back where you started. Recognising that early is the difference between a two-minute detour and a mangled working tree.