3.4 Resolving Merge Conflicts

Prerequisites: Branches and Merges

Estimated time: 15 minutes

Exercise environment: Continue using the same temporary repository

You are ready to continue when: you can create, explain, resolve, and cancel a single conflict

Fast-forward merges are quiet because the mainline has no fork. Make two branches edit the same configuration, and Git encounters a question it cannot answer for you. A conflict is not repository corruption; two histories changed the same place, and a person must decide the final meaning.

Creating Conflicts in the Practice Repository

printf '%s\n' 'color=blue' > settings.txt
git add settings.txt
git commit -m 'Add default color'

git switch -c color-red
printf '%s\n' 'color=red' > settings.txt
git commit -am 'Choose red'

git switch main
git switch -c color-green
printf '%s\n' 'color=green' > settings.txt
git commit -am 'Choose green'

git switch main
git merge color-red
merge_status=0
git merge color-green || merge_status=$?
test "$merge_status" -eq 1
git status

The file will contain:

| <<<<<<< HEAD
| color=red
| =======
| color=green
| >>>>>>> color-green

The left | is just a prefix for documentation display and does not belong to the file content; real conflict markers start from the beginning of the line.

• The side with HEAD comes from the version of the file before the merge in the current branch.
• The other side comes from the commit being merged in.
• Choosing either side does not guarantee a correct result. Check the configuration constraints and intended behavior.

Resolve and Verify

printf '%s\n' 'color=purple' > settings.txt
git diff --check
git add settings.txt
git status
git commit -m 'Resolve color configuration conflict'
git log --graph --oneline --decorate --all

Real projects should run corresponding tests before and after git add to ensure there are no residual conflict markers:

git grep -n -E '^(<<<<<<<|=======|>>>>>>>)' -- ':!*.md' || true

This search may falsely flag legitimate text or fail to detect some cases due to exclusion rules, so it can only serve as an auxiliary check.

Don't Continue with This Merge

This is an alternative to resolving and committing. Use it while the earlier merge is still conflicted; do not run it after committing the resolution:

git merge --abort

It often returns to the state before the merge began. If there are uncommitted changes when starting the merge, Git may not be able to fully recreate the original environment; it's more reliable to keep the workspace clean before the merge. The processes for resolving conflicts with rebase, cherry-pick, and revert have their own --continue, --abort steps, so check the git status provided for the current operation hint first.

Graphical merge tools can help you compare, but the final semantics are still up to you. After completion, you must review the diff and run tests.

→ Next: Remote Repository