Sooner or later, every developer runs into it. You try to merge two branches, and Git suddenly slams on the brakes. This is a merge conflict, and it happens when Git finds competing changes on the exact same lines of the same file.

It's not an error message. It's Git pausing the process and asking for a human to step in. This is a safety feature, designed to prevent you from accidentally overwriting someone else's work. Git is essentially saying, "I have two different sets of instructions for this spot, and I need you to decide which one to keep."

Why Merge Conflicts Happen in Git

The image above gets to the heart of it: parallel development. Every branch is its own independent timeline of work. Conflicts are just the natural result of trying to weave those timelines back together after they’ve changed the same bit of code.

Think of them less as a failure and more as a communication checkpoint. They're a sign that your team is actively working in parallel—which is exactly what Git branching is for. All Git is doing is raising a flag and asking for clarification before moving forward.

Common Scenarios That Create Conflicts

If you know what causes conflicts, you can often see them coming and sometimes even avoid them. Most of them boil down to a few familiar situations I've seen countless times.

• Working on the Same Feature: This is the classic scenario. Imagine two developers, Alex and Blair, are both working on the user login page. Alex is in login.js adding new validation logic. At the same time, Blair is refactoring that same file for better performance. When they both try to merge their branches back into main, Git is almost guaranteed to find a conflict because the same lines in login.js were changed in two different ways.
• Divergent Branch Histories: This happens when you forget to pull the latest changes from the remote before you start coding. The main branch moves on with everyone else's commits, but your new feature branch is based on an older, outdated version. By the time you’re ready to merge, your history and the main branch's history have drifted so far apart that overlapping changes are much more likely.
• Refactoring Shared Code: Let's say a developer decides to refactor a common utility function that's used all over the application. If another developer simultaneously uses that original function in a new feature, a conflict is practically inevitable. One branch is expecting the old function signature, while the other is introducing a completely new one.

Key Takeaway: A merge conflict is not a bug. It is a logical and necessary pause initiated by Git when it encounters ambiguous instructions. Your job is to provide the clarity Git needs to proceed.

Merge conflicts are a frequent and well-known challenge on any development team. In fact, one extensive analysis of over 6,300 merge conflicts found that about 62% of them happened in development-related projects. This just goes to show how common they are in the day-to-day grind of coding.

Resolving Conflicts Directly in the Command Line

When git merge suddenly stops and screams about a conflict, the command line is your most direct path forward. It might feel a bit intimidating at first, but tackling it this way gives you absolute control over the outcome. It's the classic, fundamental way to resolve conflicts in Git, and a skill every developer should have in their back pocket.

The first thing to do is always to figure out what just happened. After a merge fails, Git leaves your repository in a conflicted state. Running git status is your best friend here. It will clearly list the files that need your attention under an "Unmerged paths" heading, giving you a precise to-do list of exactly where the problems lie.

This breakdown shows the core CLI workflow for fixing a conflict, from spotting the trouble spots to finalizing the merge.

As the visual shows, Git walls off the competing code with special markers. It's up to you to manually edit the file before you can move on.

Decoding the Conflict Markers

Once you open a conflicted file in your favorite editor, you'll see the battlefield Git has marked out for you. These markers are your guide to understanding the clash.

• <<<<<<< HEAD: Everything below this line and before the ======= is from your current branch—what you had before the merge even started. Think of it as your local version.
• =======: This is the dividing line. It separates your local changes from the incoming ones.
• >>>>>>> [branch-name]: Everything between the ======= and this line is from the branch you're trying to merge in. This is the new stuff.

Basically, Git is presenting you with two different versions of the same code block, side-by-side, and asking you to make the final call.

Manually Editing the Conflicted File

With the conflict markers in plain sight, it’s time to make a decision. You really have three ways to go, and the right choice depends entirely on the context of the changes.

1. Choose One Version
The simplest solution is to just pick a side. If the incoming changes are what you want, you delete everything from <<<<<<< HEAD down to =======, and also get rid of the >>>>>>> line. If your local changes are the correct ones, you do the opposite. Easy.

2. Combine Both Changes
More often than not, both developers added something valuable. Maybe one person added a new color property to a CSS rule while another added a font-size. In this scenario, you'd manually edit the file to include both properties, then delete all the conflict markers.

3. Write Something New
Sometimes, seeing the two conflicting changes together makes you realize that neither of them is quite right. The conflict might expose a deeper logical issue. When that happens, you have the power to scrap both versions and write a completely new piece of code that solves the problem correctly.

Staging and Committing Your Resolution

After you’ve edited each conflicted file and removed every last <<<<<<<, =======, and >>>>>>> marker, you need to tell Git you're done. It's a critical two-step process.

First, you stage the resolved file with git add. This signals to Git that you've officially fixed the conflict for that particular file.

git add path/to/resolved/file.js

Once you've staged all the files that were in conflict, you can finally complete the merge. Running git commit will open your editor with a pre-populated commit message, usually something like "Merge branch 'feature-branch-name'". You can keep this message as is or add more context.

Save it, and with that final commit, the merge is complete. Your project history is clean once again. If you're curious about other approaches, you can also explore different ways to handle merge conflicts effectively.

Of course, the command line gives you raw power, but let's be honest—it's not always the most intuitive way to handle a merge conflict. This is where visual merge tools, often called GUIs (Graphical User Interfaces), really shine. They step in to offer a much clearer, more manageable experience.

Many of these tools are already baked into your favorite code editor, like VS Code, or come as standalone apps like GitKraken or Sourcetree. Their biggest win? They transform those abstract conflict markers into a concrete, side-by-side comparison. Instead of trying to mentally parse a bunch of <<<<<<< HEAD blocks, you get an interactive display that drastically cuts down on the mental gymnastics needed to fix a messy merge.

This visual clarity is a game-changer, especially when you're untangling conflicts that span multiple files. It helps you sidestep the simple mistakes that are all too easy to make when you're tired and staring at a wall of text in the terminal.

The Power of the Three-Way Merge View

The absolute standout feature in most visual tools is the three-way merge view. It breaks down the conflict into three distinct panes, giving you a complete picture of what's going on:

• Your Changes (Current): This pane shows the code from your current branch (HEAD). It’s what you wrote.
• Incoming Changes (Theirs): This shows the version of the code from the branch you're trying to merge in. It's what the other person wrote.
• Result: This is a live preview of the final, merged file. As you click and choose which changes to keep, this pane updates in real-time.

This setup provides instant context. You see exactly what you did, what your teammate did, and what the final code will look like, all at once. Most tools place clickable buttons right above each conflict—"Accept Current," "Accept Incoming," or even "Accept Both"—making the process incredibly straightforward.

A three-way merge view removes all the guesswork. By visualizing your changes, the incoming changes, and the final result simultaneously, you can make decisions with confidence and avoid introducing new bugs while fixing the old ones.

Picture this scenario: you've refactored a function's name, while another developer has added a new parameter to the old function. In a visual tool, you could simply click "Accept Incoming" to grab the new parameter, then manually edit the function name right there in the "Result" pane to finish your refactor. It’s this blend of one-click actions and manual editing that makes these tools so efficient.

Choosing Your Tool and Configuring Git

A lot of developers already have a powerful merge tool at their fingertips and don't even realize it. VS Code, for instance, has a fantastic built-in merge editor that pops up automatically whenever you open a conflicted file.

For those who prefer a dedicated application, tools like GitKraken and Sourcetree offer robust features that go way beyond just resolving conflicts.

To get Git to launch your favorite tool automatically, you just need to tweak your configuration. For example, to set up VS Code as your default merge tool, you’d run these two commands:

git config --global merge.tool "vscode"
git config --global mergetool.vscode.cmd "code --wait $MERGED"

Now, the next time you run git merge and hit a conflict, you can just type git mergetool. This command will fire up your visual editor, walking you through each conflicted file one by one in a structured, visual, and much less painful way.

Comparing CLI and Visual Merge Tools

To help you decide which approach fits you best, here's a quick comparison. There's no single "right" answer; it often comes down to personal preference, the complexity of the conflict, and your comfort level with different tools.

Ultimately, both methods get the job done. While the CLI is a fundamental skill every developer should have, don't hesitate to reach for a visual tool when things get complicated. They exist to make your life easier.

Of course, here is the rewritten section, designed to sound like it was written by an experienced human expert and matching the provided style examples.

Proven Strategies to Minimize Future Conflicts

While knowing how to untangle a nasty merge conflict is a vital skill, the real win is avoiding them in the first place. This means shifting your mindset from reactively fixing problems to proactively preventing them. The best defense is a good offense, and that starts with smart team habits long before you ever type git merge.

Believe it or not, the most powerful strategy has nothing to do with code—it's all about communication. A quick chat on Slack or a status update in your project management tool can head off probably 80% of potential conflicts. When developers know who is working on what, they can coordinate their efforts from the start, saving hours of frustration down the road.

Sync Early and Sync Often

One of the biggest culprits behind monster merge conflicts? A long-lived feature branch that has drifted miles away from the main line of development. The longer a branch exists in isolation, the more painful the eventual merge will be.

To fight this, get into the habit of constantly syncing your local branch with the latest changes from main. Before you write a single line of new code for the day, run git pull origin main. This ensures you're building on the most current version of the codebase.

Just as crucial, pull again right before you're ready to push your own changes. This final sync usually surfaces small, manageable conflicts—the kind you can fix in a few minutes—instead of one giant, soul-crushing one. For a closer look at this and other preventative tactics, you can explore more ways to avoid merge conflicts entirely.

Expert Tip: I always run git pull --rebase origin main before I push. Using the --rebase flag is my secret weapon. It replays my local commits on top of whatever is new on main, keeping my commit history clean and linear. The final merge into the main branch becomes incredibly smooth as a result.

Keep Your Pull Requests Small and Focused

Massive pull requests that touch dozens of files are a recipe for disaster. They're a nightmare for your colleagues to review, and they are practically begging to create complex merge conflicts. The solution is beautifully simple: smaller, more focused PRs.

A pull request should do one thing and do it well. Think of it as a single, atomic unit of work.

• Good PR: "Add password validation to the user signup form."
• Bad PR: "Update user auth, refactor logging, and change button colors."

Smaller PRs are easier to understand, faster to review, and far less likely to clash with someone else's work. This discipline goes beyond just avoiding conflicts; it improves overall code quality and team velocity. For a deeper dive into building these kinds of habits, it's worth exploring a guide on Version Control Best Practices for Modern Development Teams.

This isn't just a niche problem; it's a universal developer experience. Nearly 90% of software developers have wrestled with merge conflicts. Yet, the data shows that teams who are diligent with their version control practices report a 20% boost in productivity and a 30% reduction in coding errors. The proof is in the pudding.

How to Handle Advanced Conflict Scenarios

So far, we've been wrestling with conflicts inside text files. But what happens when the clash involves something you can't just open and edit, like a compiled file or an image? These situations call for a different set of tactics beyond just hunting for conflict markers.

The most common non-text conflict involves binary files. Picture this: you and a teammate both commit a new version of the company logo. Git will flag it as a conflict, but when you open that PNG file, you won't find any <<<<<<< HEAD markers. You just have to pick one version to keep.

This is where you need to be decisive. To keep your version of the file and toss the incoming one, you can use the --ours strategy.

Keep your version of the binary file

git checkout --ours path/to/binary/file.png

After choosing, you have to stage the file

git add path/to/binary/file.png

On the flip side, if your teammate's version is the one everyone agreed on, you can use --theirs to accept their change completely.

The Big Red Abort Button

Sometimes, a merge goes so sideways that fixing it feels like more trouble than it's worth. You might be staring at a dozen confusing conflicts, or worse, you realize you merged the wrong branch entirely. In those moments, git merge --abort is your escape hatch.

Running this one command instantly stops the merge and rewinds your repository to the exact state it was in before you started. It's a clean getaway, leaving no trace of the merge attempt.

Key Takeaway: Never be afraid to abort a messy merge. It’s often faster and safer to git merge --abort, pull the latest changes, and try again with a cleaner slate than it is to untangle a complex web of conflicts.

When a File Is Deleted vs. Modified

One of the most head-scratching situations is the "deleted by us, modified by them" conflict. This happens when you delete a file in your branch, but in another branch, a teammate has been busy modifying that very same file. Git gets stuck—it doesn't know whether to honor the deletion or keep the modified file.

To resolve this, you have to make an explicit choice.

• To keep the file (along with the other developer's changes), you just need to git add the file.
• To delete the file for good (and discard the modifications), you need to use git rm.

For instance, if the file really is obsolete and needs to go:

Tell Git to remove the file, resolving the conflict

git rm path/to/conflicted/file.js

Getting comfortable with these commands will give you the confidence to handle just about any merge scenario Git can throw at you. For more hands-on examples, there are some great guides that can help you resolve Git merge conflicts in even more detail.

Of course. Here is the rewritten section, crafted to sound like an experienced developer sharing practical advice in a natural, human-written tone.

Your Git Conflict Questions, Answered

Even with the best intentions, you're going to have questions when you're knee-deep in conflict markers. Let's tackle some of the most common stumbling blocks I see developers run into when it's time to git resolve conflicts.

"Help, I Messed Up the Merge! Can I Undo It?"

Absolutely. We've all been there. You get halfway through resolving a tangled mess and realize you've made things worse, not better.

If you haven't committed the merge yet, there's a clean escape hatch: git merge --abort.

This command is your best friend when a resolution goes sideways. It stops the merge process cold and rewinds your repository to the state it was in right before you started. No harm, no foul.

What’s This merge.conflictstyle Thing?

By default, when you get a conflict, Git just shows you two versions of the code: what's on your branch (HEAD) and what's on the branch you're trying to merge in. It's functional, but it often lacks context.

Many seasoned developers, including some of the folks who work on Git itself, swear by a different setting: zdiff3.

git config --global merge.conflictstyle zdiff3

What this does is add a third block of code to the conflict markers—it shows you the original code from the common ancestor, before either branch made its changes. Seeing how both versions diverged from the same starting point is incredibly insightful and often makes the right resolution path immediately obvious.

How Is a Rebase Conflict Different?

The process for fixing a conflict during a git rebase feels almost identical to a merge conflict. You’ll open the file, edit out the conflict markers to create the code you want, and then git add the fixed file.

The key difference is the next step. Instead of committing, you run git rebase --continue.

This tells Git, "Okay, I've fixed this one, now you can move on and apply the next patch in the sequence." And just like with merging, if you feel like you're in over your head, git rebase --abort is your ticket out, cancelling the entire rebase operation.

Pro Tip: If you're a heavy user of rebase, do yourself a favor and enable rebase.autostash. It automatically stashes any local, uncommitted work before the rebase begins and pops it back when it's done. This can prevent a whole class of unnecessary conflicts with your own work-in-progress.

What's the Real Difference Between --ours and --theirs?

This is easily one of the most confusing parts of Git conflict resolution, because the meaning of these terms flips depending on what you're doing. Getting this wrong can mean you accidentally discard the wrong changes, so it's critical to understand.

• When Merging: --ours is your current branch (HEAD). --theirs is the code from the other branch you're merging in. Simple enough.
• When Rebasing: It's the complete opposite. --ours is the upstream branch you're rebasing onto (like main). --theirs refers to the commits from your feature branch that are being replayed on top.

Always take a second to confirm which operation you're performing before reaching for these options. It's a powerful shortcut, but one that demands a bit of caution.

At Mergify, we believe the best way to deal with merge conflicts is to prevent them from happening in the first place. Our Merge Queue and automated CI checks ensure that only stable, up-to-date code ever lands in your main branch, stopping most conflicts before they can slow your team down. Find out how Mergify can streamline your development cycle.