A conflict is Git refusing to guess which edit wins. The fix is a text edit plus two commands. If you want out before touching anything, git merge --abort restores the pre-merge state.
🎙️ Published & recorded: ·
Start with status, not with a search-and-replace across the project. Under Unmerged paths, Git names every file that still needs a decision. If the merge was accidental or you are not ready to resolve it, abort now. Abort is not a repair command after you have committed; it is the clean exit while a merge is still in progress.
git status
# Unmerged paths:
# both modified: config.py
# Leave the merge and return to the pre-merge state:
git merge --abortfatal: There is no merge to abort (MERGE_HEAD missing).Run git status and read its first lines. You may be in a rebase, cherry-pick, or revert rather than a merge. Use the matching command, such as git rebase --abort or git cherry-pick --abort. If status says the working tree is clean, the merge was already finished or never started.
Open one conflicted file. The text above the equals line is the current branch, labelled HEAD. The text below it is the incoming branch. Keep either side, combine them, or write a third result. Then delete all three marker lines. The goal is not to make the markers disappear; it is to leave the file in the state the product actually needs.
<<<<<<< HEAD
timeout = 30 # current branch
=======
timeout = 60 # incoming branch
>>>>>>> feature-x
# Edit to the intended result, with no markers:
timeout = 60
# Mark this file resolved, then finish:
git add config.py
git commit # save and close the pre-filled messageerror: Committing is not possible because you have unmerged files.fatal: Exiting because of an unresolved conflict.Run git status. For every file still under Unmerged paths, resolve the content and run git add path/to/file. Search the project for seven less-than signs before committing; an overlooked marker can be valid text to Git and invalid syntax to your application. Run the relevant test before the final commit.
Use ours or theirs only when one complete file should win. It is appropriate for a generated lock file when your team will regenerate it immediately afterward. It is a bad shortcut for source code containing two intentional fixes. During a normal merge, ours is the branch you had checked out and theirs is the branch being merged in.
# Keep the whole file from the current branch:
git checkout --ours config.py
git add config.py
# Keep the whole file from the incoming branch:
git checkout --theirs config.py
git add config.py
# For a lock file, regenerate and test after choosing:
npm install
git add package-lock.jsonA rebase uses the same markers and the same edit-and-add process, but continue with git rebase --continue and escape with git rebase --abort. Ours and theirs are counterintuitive during rebase because Git is replaying your commit onto another base. Read the marker labels and inspect the content; do not choose by the pronoun alone.
Conflicts become difficult when branches are old, commits mix formatting with behavior, or two people unknowingly redesign the same area. Pull often, keep branches short-lived, and separate mechanical formatting from logic changes. After resolving, inspect the staged diff. That catches the common mistake where the file compiles but one side’s necessary behavior was silently dropped.
git diff --check # catches leftover whitespace trouble
git diff --cached # inspect exactly what the merge will commit
git status
# Habits that prevent giant conflicts:
git pull often
# keep branches short-lived (days, not months)
# do not mix whole-file formatting with logic changesIf your app later reports a syntax error on a line beginning with seven less-than signs, the merge was committed before the text was resolved. Open the file, decide the correct content, remove all marker lines, run the test or parser again, stage the repair, and commit it. Picking a side blindly can remove a bug fix even when the syntax is valid, so review behavior as well as punctuation.