Why Conflicts Happen

A merge conflict means Git found overlapping changes that it cannot safely combine on its own. It is not evidence that the repository is corrupted, and it does not mean the merge has already been discarded. Git pauses the merge so a person can decide what the final content should be. Changes in separate parts of a file often merge automatically; edits to the same line or overlapping block are common causes of a conflict.

The goal is not simply to make Git stop reporting a conflict. You must inspect both intended changes, decide what the file should say, remove the conflict markers, stage the resolved file, and complete the merge. The right answer depends on the project’s facts. Git can identify competing versions, but it cannot decide which status, requirement, or behavior is correct.

Create Competing Changes

The following exercise creates an isolated repository and a realistic conflict in a release checklist. Run these commands in a Bash-like terminal where a new folder named conflict-practice does not already exist. They use git switch, available in Git 2.23 and later. The commands set an identity only for this repository, so you do not need to change your global Git configuration.

git init conflict-practice
cd conflict-practice
git config user.name "Avery Chen"
git config user.email "avery@example.com"
printf 'Release checklist\nStatus: draft\nOwner: team\n' > release.txt
git add release.txt
git commit -m "Add release checklist"
git branch -M main
git switch -c update-status
printf 'Release checklist\nStatus: in review\nOwner: team\n' > release.txt
git add release.txt
git commit -m "Mark checklist in review"
git switch main
printf 'Release checklist\nStatus: approved\nOwner: team\n' > release.txt
git add release.txt
git commit -m "Approve release checklist"
git switch update-status
git merge main

The initial commit gives both branches a shared starting point. Each branch then changes the same status line differently. The final merge command tries to bring main into update-status. Git should report a conflict in release.txt and leave update-status checked out. A conflict can make the merge command return a nonzero result; that is expected in this exercise. The merge is paused, not complete, and you should continue by inspecting the repository rather than repeating the merge command.

Inspect Both Versions

Start with git status. It identifies release.txt as unmerged, and its short form commonly shows UU beside the filename when both branches modified it. Then open release.txt in an editor or print it in the terminal. Git has placed conflict markers around the competing sections. The opening marker labels the current side as HEAD, which is update-status here; a separator divides the alternatives; the closing marker labels the incoming side as main.

Do not assume that HEAD means the default branch. It means the branch currently checked out when the merge began. Read the surrounding lines as well as both alternatives: a conflict may cover more than the one line that changed, and nearby content can carry important context. Git diff can provide a view of the unresolved change, but the file itself is the clearest way to review the exact text that must be resolved. If either version is unclear, check with the change’s author or consult the project requirement before deciding.

Edit and Complete the Merge

For this exercise, assume the release has now been approved, so the final status should be approved for release. Keep the checklist title and owner line, and replace the marked conflict region with the intended final text. Edit in your normal text editor, or use the following command to write the complete file. Replacing the whole short file makes the desired result explicit and ensures no conflict-marker lines remain.

cat > release.txt <<'EOF'
Release checklist
Status: approved for release
Owner: team
EOF
git diff --check
git add release.txt
git diff --cached --check
git diff --cached -- release.txt
git status
git commit -m "Resolve release checklist conflict"

The first diff check looks for whitespace errors in the working-tree change; it does not decide whether the content is semantically correct, so inspect the staged diff as well. Staging the file tells Git that you resolved its conflict. The status output should no longer list an unmerged path, and the staged diff should show the intended final file. The commit completes the merge and records the resolution. If Git still reports unmerged files, check whether every conflicted file was edited and staged. If you decide to abandon the merge instead, git merge --abort can return you to the pre-merge state; avoid it when you have valuable uncommitted work from before the merge.

Validate the Result

After committing, verify the file’s content rather than treating a successful commit as proof that the resolution is right. The first command below should print the exact status line. The short status command should print nothing when the working tree is clean. The log should show the new merge commit and both lines of branch history, making it possible to confirm that the merge was completed rather than replaced with an unrelated commit.

grep -Fx "Status: approved for release" release.txt
git status --short
git log --oneline --graph --decorate -5

Common mistakes include deleting the markers but keeping the wrong alternative, choosing an entire side without checking whether it drops useful changes, and editing the file but forgetting to stage it. Also inspect for leftover marker lines before committing; Git cannot infer that a text line which resembles a marker was accidentally left behind. For application code, run the relevant tests after the merge too. For this checklist, reading the final file and checking the exact expected line are suitable content checks.

A conflict resolution is a small review decision embedded in a Git workflow. Inspect the current and incoming versions, make a deliberate edit, stage every resolved file, complete the merge, and validate both the content and repository state. That process scales to source files and documentation alike, even when the right resolution is to combine information rather than select one side unchanged.