How to Resolve Merge Conflicts in Git Repository

Resolving merge conflicts in Git happens when branches edit the same lines or one deletes what the other changes—Git pauses the merge and marks files with conflict markers like <<<<<<<, =======, and >>>>>>>. Run git status to spot conflicted files, edit them manually to pick or blend the changes, then git add the fixed files and git commit to finish. Tools like git mergetool or VS Code make it visual if command-line editing feels brutal.

Contents

• What Causes Merge Conflicts in Git
• Spotting and Checking Conflicts
• Step-by-Step: Resolving Line Change Conflicts
• Handling Deleted or Renamed File Conflicts
• Using Visual Merge Tools like Git Mergetool
• Advanced Strategies and Abort Options
• Preventing Merge Conflicts Next Time
• Sources
• Conclusion

What Causes Merge Conflicts in Git

Picture this: two developers on separate branches tweak the exact same function in app.js. You try git merge feature-branch, and boom—Git throws up its hands. Merge conflicts pop up precisely when changes overlap: same lines edited differently, or one branch nukes a file the other modifies. It’s not a bug; it’s Git protecting your code from automatic overwrites.

Why does this hit so often? Parallel work on shared files, long-lived branches without rebasing, or sneaky whitespace diffs. According to the official Git documentation, Git handles most merges cleanly via three-way diffs, but true conflicts demand human judgment. And yeah, git pull or pull requests trigger them too—anything merging divergent histories.

Ever wondered if ignoring spaces helps? Spoiler: sometimes. But let’s get to fixing them first.

Spotting and Checking Conflicts

After a failed git merge or git pull, Git doesn’t crash. It leaves you in a limbo state. First move? git status. It’ll scream “both modified” or “unmerged paths” and list the culprits. Files show up red in your terminal or IDE.

Open one—say README.md. Inside, you’ll see ugly markers:

<<<<<<< HEAD
Your current changes here
=======
Their branch's version
>>>>>>> feature-branch

That’s Git’s way of saying, “Pick one, mix 'em, or rewrite.” No panic needed. Tools like VS Code highlight this visually, but command line works fine. Run git diff on the file for a side-by-side peek if you’re curious.

Quick tip: If it’s a mess across many files, note them down. Git won’t let you commit until everything’s staged.

Step-by-Step: Resolving Line Change Conflicts

This is the bread-and-butter fix for most git merge conflicts. Here’s how, straight from GitHub’s command-line guide.

1. Edit the file in your favorite editor. Hunt those markers.
2. Decide: Keep HEAD’s version? Theirs? A combo? Delete the markers entirely.

• Example: If HEAD has a better function signature, yank the ======= block and >>>>>>> section.

3. Save. Then git add filename. Repeat for all conflicted files.
4. git commit. Git auto-generates a merge message, or tweak it with -m "Fixed merge conflicts in app.js".

Done. Push if needed. But what if you hate manual edits? Jump to mergetool later.

Real-world snag: Massive files. Scroll carefully—markers nest in blocks. Test post-resolution with git diff --cached to verify.

And pro move: Use git checkout --ours filename to auto-pick your branch, or --theirs for the incoming one. Fast, but risky if you’re not sure.

Handling Deleted or Renamed File Conflicts

Not all conflicts are line edits. Sometimes one branch deletes config.yaml while yours adds features. git status flags it as “deleted by them” or “added by us.”

Choices:

• Keep it: Edit to resolve any other issues, then git add config.yaml.
• Ditch it: git rm config.yaml.

Atlassian’s tutorial nails this—Git just needs your decision staged. Commit as usual.

Renames? Trickier. Git detects them via similarity, but conflicts arise if paths diverge. git status shows “both added” or similar. Stash changes, resolve, unstash if needed.

Short version: Always git add or git rm to signal “I chose.”

Using Visual Merge Tools like Git Mergetool

Command-line purists, skip ahead. But if markers make your eyes bleed, configure git mergetool. This Medium guide walks vimdiff or KDiff3 setup.

Bash these:

git config --global merge.tool vimdiff
git config --global merge.conflictstyle diff3

Then git mergetool. Boom—three panes: yours, theirs, base, and result. Arrow keys or mouse to copy chunks. Save, exit. Git adds automatically.

Reddit folks rave about KDiff3 or IntelliJ’s built-in resolver too. VS Code? Right-click conflicted file, “Open Merge Editor.” No config hassle.

Why bother? Faster for complex diffs. Drawback: Learning curve if you’re tool-shopping.

Advanced Strategies and Abort Options

Stuck mid-merge? git merge --abort resets everything. Clean slate, per Git’s advanced merging docs.

Whitespace woes? git merge -Xignore-space-change. Or rebase instead: git rebase main often sidesteps conflicts by replaying commits linearly.

Pull requests with conflicts? Resolve locally, force-push, or use GitHub’s web editor for simple cases.

Rerere (reuse recorded resolution) auto-resolves repeats: git config --global rerere.enabled true. Underrated gem.

Preventing Merge Conflicts Next Time

Fixing sucks—avoid them. Short-lived branches, frequent rebases (git rebase main before merging), or trunk-based dev. Communicate on shared files. Pre-commit hooks for whitespace.

Tools: GitHub’s merge queue or Draft PRs delay merges till green.

Still hit one? Now you know the drill.

Sources

1. Resolving a merge conflict using the command line - GitHub Docs
2. How to Resolve Merge Conflicts in Git? | Atlassian Git Tutorial
3. Git - Advanced Merging
4. Tools to Master Merge Conflicts | Medium
5. r/git on Reddit: Best UX for merge conflict resolving

Conclusion

Mastering merge conflicts in Git boils down to git status, edit/add/commit—simple, but it saves your repo. Lean on mergetool for speed, abort when overwhelmed, and rebase proactively to dodge future headaches. Next time a git merge conflict hits, you’ll handle it like a pro, keeping your team shipping code smoothly.