How to resolve merge conflicts in Git (2026)
Quick Answer
To resolve merge conflicts in Git, first identify which files are conflicted, then open each file and decide which changes to keep, combine, or rewrite. After editing, mark the conflict as resolved with git add, then complete the merge or rebase with the appropriate command. If you are unsure which version is correct, stop and check the project history or ask the teammate responsible before committing a bad merge.
Overview
Merge conflicts happen when Git cannot automatically combine changes from two lines of development. This usually occurs when the same part of a file was changed in different branches, when one branch deleted a file that another branch edited, or when a rebase or cherry-pick replays commits onto code that has moved on. The conflict is not the problem by itself; the real task is deciding what the code should look like now. A good conflict-resolution process is: confirm whether you are in a merge, rebase, or cherry-pick; list conflicted files; inspect the conflict markers or use a merge tool; resolve one file at a time; run tests or at least a build check; then mark files resolved and finish the operation. This order matters because Git only knows the conflict is fixed after you stage the corrected file, and a clean stage without testing can still leave the project broken. If the codebase is shared, do not blindly accept 'ours' or 'theirs' across many files unless you fully understand the impact. In some teams, the safest fix is to abort the operation, update your branch, and re-apply your changes more carefully. Use project documentation, commit history, and code owners when the intent of the code is unclear.
Who this is for
Developers using Git on local branches, whether working alone or in a team, who need to fix merge, rebase, or cherry-pick conflicts safely.
What you’ll need
- A Git repository with the conflicted branch checked out
- Command-line access to Git
- A text editor or IDE that can show and edit conflict markers
- Basic knowledge of the intended code changes
- Ability to run the project's tests or build checks if available
Before you start
Run git status first. It tells you whether you are in the middle of a merge, rebase, or cherry-pick, and lists the files Git still considers unmerged. If you have unrelated local changes, consider stashing or committing them before continuing so you do not confuse new edits with conflict-resolution work.
Step-by-step
- 1
Check what kind of conflict you are in
Run git status. Read the message carefully to see whether Git says you are merging, rebasing, or cherry-picking. Also note the list of 'both modified', 'deleted by us', 'deleted by them', or similar states.
Why: The finish command is different depending on the operation. A merge is usually completed with a commit, while a rebase or cherry-pick needs you to continue that specific process.
- 2
Inspect the conflicted files
Run git status to list unmerged files, and if needed use git diff or git diff --name-only --diff-filter=U to review them. Open each conflicted file and look for conflict markers such as <<<<<<<, =======, and >>>>>>>.
Why: You need to know exactly which files and sections Git could not combine automatically before making changes.
- 3
Choose the correct resolution for each conflict
For each conflict, decide whether to keep your branch's version, the incoming version, or a manual combination of both. In a text editor, remove the conflict markers and leave only the final content you want. For deleted-versus-modified conflicts, either restore and edit the file, or confirm it should stay deleted. For renamed or moved files, check the current project structure before deciding.
Why: Git can detect a conflict, but it cannot decide the intended behaviour of the code. The right answer is based on project logic, not on which branch changed later.
- 4
Use a merge tool if the file is hard to compare
If a conflict is large or repetitive, run a merge tool such as git mergetool or use your IDE's compare-and-merge view. Work through one file at a time and save the resolved result.
Why: Visual comparison tools reduce the risk of missing lines, duplicating code, or accidentally leaving conflict markers behind.
- 5
Mark files as resolved
After editing a file and checking that the conflict markers are gone, stage it with git add <file>. Repeat until git status no longer shows unmerged paths.
Why: Git only treats a conflict as resolved when the corrected file is staged. Saving the file alone is not enough.
- 6
Complete the operation correctly
If you were merging, create the merge commit if Git does not do so automatically. If you were rebasing, run git rebase --continue. If you were cherry-picking, run git cherry-pick --continue. If you realise the whole attempt is wrong, use the relevant abort command instead, such as git merge --abort, git rebase --abort, or git cherry-pick --abort.
Why: The repository stays in a special in-progress state until you either continue or abort, so finishing properly prevents a half-resolved history.
- 7
Test before pushing
Run the project's tests, linter, build, or at least start the application if that is the normal check. Then review the final diff and commit history before you push.
Why: A conflict can be syntactically resolved but still break behaviour. Testing catches incorrect combinations that Git cannot detect.
Why this works
Git stores snapshots and uses merge algorithms to combine different histories, but it stops when two changes cannot be reconciled with confidence. Conflict resolution works because you manually create the intended final version, then stage it so Git can record that version as the new truth in the repository history.
Common mistakes to avoid
- Leaving conflict markers in a file and committing them
- Using 'accept ours' or 'accept theirs' on many files without understanding the code impact
- Forgetting to run git add after editing resolved files
- Running the wrong finish command, such as trying to commit during a rebase without continuing it
- Resolving code conflicts without running tests or a build check
Troubleshooting
git status shows 'both modified' for one or more files
Open each file, remove the conflict markers, keep the correct final code, then stage the file with git add.
A file was deleted in one branch but edited in the other
Decide whether the file should still exist. If it should exist, restore and edit it, then git add it. If it should stay deleted, remove it and stage the deletion.
You are in the middle of a rebase and normal commit commands are confusing the process
Use git status to confirm the rebase state, resolve the files, stage them, then run git rebase --continue. If the rebase should not proceed, use git rebase --abort.
You resolved the file, but Git still says it is unmerged
Make sure you staged the resolved file with git add. Also check that no conflict markers remain and that every conflicted file has been handled.
There are too many conflicts after your branch fell far behind
Consider aborting, updating from the target branch in smaller increments, then reapplying your changes gradually. Reviewing commit history file by file can be easier than resolving one large conflict burst.
The project builds before the merge but fails after conflict resolution
Review the resolved sections for duplicated logic, missing imports, removed function arguments, or mismatched configuration. Compare against both parent branches and rerun tests.
Compare your options
Manual editing in a text editor
Best for: Small, straightforward conflicts where you understand the code well
Pros: Fast, no extra setup, full control over final content
Cons: Easy to miss lines or leave markers in complex conflicts
IDE or git mergetool
Best for: Large or repetitive conflicts across multiple files
Pros: Clear side-by-side comparison, easier to combine changes accurately
Cons: Tool behaviour varies, and it can still be dangerous if you do not understand the code
Abort and re-apply changes
Best for: Messy conflicts where your branch is very outdated or the intent is unclear
Pros: Can produce a cleaner history and simpler conflict set
Cons: Takes longer and may require careful rework
| Option | Best for | Pros | Cons |
|---|---|---|---|
| Manual editing in a text editor | Small, straightforward conflicts where you understand the code well | Fast, no extra setup, full control over final content | Easy to miss lines or leave markers in complex conflicts |
| IDE or git mergetool | Large or repetitive conflicts across multiple files | Clear side-by-side comparison, easier to combine changes accurately | Tool behaviour varies, and it can still be dangerous if you do not understand the code |
| Abort and re-apply changes | Messy conflicts where your branch is very outdated or the intent is unclear | Can produce a cleaner history and simpler conflict set | Takes longer and may require careful rework |
Alternatives
- Use git checkout --ours or git checkout --theirs on a specific conflicted file when you deliberately want one full side, then review before staging
- Use an IDE's built-in merge editor instead of raw conflict markers
- Abort the merge or rebase and recreate your changes on top of the latest target branch
Pro tips
- Resolve one file at a time and stage it immediately once you are confident
- Use git log, git blame, or your hosting platform's pull request history to understand why each side changed
- If a generated file is conflicted, check whether it should be regenerated rather than hand-edited
- If the same conflict keeps happening, pull or rebase more frequently to reduce drift between branches
- Read the labels in your editor carefully: in rebase workflows, 'ours' and 'theirs' can be counterintuitive
Safety notes
- Do not force-push a rebased shared branch unless your team explicitly allows it and everyone affected understands the impact
- If you are unsure about the intended business logic, stop and ask rather than guessing
- Keep a backup branch or note the current commit hash before major conflict-resolution work so you can recover if needed
What this guide does not cover: This guide covers common text-file merge conflicts in Git and the general workflow for merge, rebase, and cherry-pick resolution. It does not cover every IDE-specific interface, binary file conflicts, advanced custom merge drivers, or project-specific branching policies.
Cost considerations
Git itself is commonly available at no cost, but mistakes in conflict resolution can be expensive in developer time, outages, or lost work. The main cost saver is disciplined review and testing before pushing shared changes.
Frequently asked questions
What causes merge conflicts in Git?+
Most conflicts happen when two branches change the same lines, one branch deletes a file that another edits, or history is being replayed during a rebase or cherry-pick onto newer code.
How do I know whether the conflict is from a merge or a rebase?+
Run git status. Git tells you whether a merge, rebase, or cherry-pick is in progress and what command to run next.
What do 'ours' and 'theirs' mean?+
They refer to different sides of the conflict, but the meaning can be confusing during rebase because the perspective changes. Always confirm with git status and inspect the actual content before accepting one side.
Can I cancel the whole operation?+
Yes, if you have not completed it and you decide the attempt is wrong, use the relevant abort command for the operation in progress, such as merge, rebase, or cherry-pick abort.
Do I need to commit after resolving conflicts?+
For a normal merge, usually yes, unless Git completes the commit automatically. For a rebase or cherry-pick, you normally stage the files and then continue that process rather than making a separate ordinary commit first.
Sources & references
Guidance on this page is traced to documented sources. Last checked 24 September 2026.
- Git Documentation - Basic Branching and Merging · official
Supports how merges work, when conflicts occur, and the basic process of resolving them before completing the merge.
- Git Documentation - git-status · official
Supports using git status to identify in-progress operations and list unmerged paths.
- Git Documentation - git-merge · official
Supports merge conflict behaviour, staging resolved files, and use of merge abort where appropriate.
- Git Documentation - git-rebase · official
Supports rebase conflict handling, continue and abort commands, and the need to resolve and stage files before continuing.
Core Git conflict-resolution workflow changes slowly, though IDE interfaces and team practices vary.