Resolve a Git merge conflict, step by step

Create the conflict

Run this Bash exercise in a new empty directory. The branch names and file are deliberately limited to this example.

git init -b main
git config user.name "DevSheet Demo"
git config user.email "demo@example.invalid"
printf "colour=blue\n" > settings.txt
git add settings.txt
git commit -m "Base colour"
git switch -c feature
printf "colour=green\n" > settings.txt
git commit -am "Feature colour"
git switch main
printf "colour=red\n" > settings.txt
git commit -am "Main colour"
git merge feature

The final command should stop with a conflict in settings.txt. That nonzero exit status is expected in this exercise.

Read the two versions

git status --short
git diff -- settings.txt

Look for UU settings.txt. In the file, <<<<<<< HEAD introduces the current branch’s text, ======= separates the versions and >>>>>>> feature ends the incoming text. These labels describe this normal merge; rebase has different context.

Write and review the final content

For this exercise choose green. Replace the whole conflicted file with the intended result, stage only that file and inspect what will be committed.

printf "colour=green\n" > settings.txt
git add settings.txt
git diff --cached
git merge --continue
git status --short

Save the merge message when the editor opens. Expected: a clean status and a merge commit. In a real project, combine the changes according to the application’s behavior and run its relevant checks before completing the merge.

Cancel or diagnose a stuck merge

While the conflict is still unresolved, git merge --abort attempts to return to the state before the merge. Commit or stash unrelated work before starting: abort may not reconstruct edits that existed beforehand.

Staging a file tells Git that you resolved it, even if conflict markers remain. Read the staged diff. Binary files, delete/modify conflicts and renames require their own decisions; replacing a text line does not cover those cases.