Merge conflicts in Git are like traffic jams in a city that promised to be driverless by 2025. They happen, they are annoying, and they will not go away just because you stare at the terminal hard enough. This guide will walk you through detecting, inspecting, resolving, and verifying merge conflicts with real git commands and a pinch of sarcasm to keep you awake.

Spot the problem files

After a failed git merge or a rough git pull run git status and let Git do the heavy lifting. It will list unmerged paths so you do not play guessing games or consult a crystal ball.

git status

Inspect what actually collided

Use git diff to see the differences and git diff --name-only to get a short list of affected files. Open the file to see conflict markers that look like a tiny legal dispute inside your source code.

git diff --name-only

# conflict markers inside a file look like this
<<<<<<< HEAD
your changes here
=======
incoming changes here
>>>>>>> feature/branch

Quick ways to compare

• Use git diff to read changes in the terminal.
• Use git mergetool to launch a visual merge tool for the faint of heart or the attention challenged.
• Use git log --merge when you want to inspect commits involved in the conflict.

Decide how to resolve the conflict

You have options, none of them involve chanting. Pick the one that fits your situation.

• Manual edit. Open the file. Remove the conflict markers. Keep the code you want. Test it or cry softly.
• Take one side. If you trust local changes use git checkout --ours path. If you prefer incoming work use git checkout --theirs path. These are blunt instruments but useful sometimes.
• Use a merge tool. For visual diffs and smarter conflict resolution launch git mergetool. It will show both sides and let you compose the final version.

Mark as resolved and commit

Once you have removed markers and shaped the file, tell Git you are done by staging the files. This is Git s way of nodding and moving on.

git add path/to/resolved_file
# once all files are staged
git commit

Git will usually prepare a merge commit message for you. Keep it honest and short. Your future self will either be grateful or very judgmental.

Test everything and push

Run your test suite and a couple of manual checks as needed. Passing tests beat a smug commit message any day. When you are happy push the fixed branch with git push and share the peace with your team.

git push

Pro tips to avoid repeat drama

• Enable automatic reuse of old resolutions with git config --global rerere.enabled true. Git will remember how you resolved similar conflicts earlier and save you time.
• Communicate in your developer workflow. Smaller merge windows and more frequent pulls reduce the chance of giant conflicts.
• Use feature branches and a consistent merge strategy. Rebase can keep history tidy but only if your team agrees on the rules.
• Prefer a good merge tool when the files are complex. Your eyeballs will thank you later.

Minimal checklist

1. Run git status to find conflicts
2. Inspect with git diff or a merge tool
3. Edit or choose a side with git checkout --ours or git checkout --theirs
4. Stage with git add and commit the merge
5. Run tests and push the branch

Resolve conflicts with a little patience and a tiny bit of dignity. Your repository will survive and your teammates will forget what happened, at least until the next feature branch collides with reality.