Resolve Merge Conflicts
Merge conflicts happen when two branches modify the same lines of code. Don't panic—they're a normal part of collaborative development. This guide teaches you how to resolve conflicts using GitHub's web editor, command line, and visual merge tools.
A merge conflict occurs when Git cannot automatically reconcile differences between two branches. This happens when both branches have changed the same lines in a file, or when one branch deleted a file while the other modified it. Git needs your help to decide which changes to keep.
Conflicts are not errors—they're a safety mechanism. Git is telling you that it found ambiguous changes and needs human guidance. With practice, resolving conflicts becomes routine. Most conflicts are small and easy to fix.
When Git encounters a conflict, it adds special markers to the affected file. These markers show you exactly what changed in each branch. Here's what a conflicted file looks like:
const greeting = "Hello from my branch";
=======
const greeting = "Hello from the other branch";
>>>>>>> feature-branch
The <<<<<<< HEAD marker shows the beginning of the conflict. The content between this marker and ======= is your current branch's version. The content between ======= and >>>>>>> feature-branch is the incoming branch's version. Your job is to edit the file to keep the correct version, then remove all conflict markers.
<<<<<<<, =======, >>>>>>>). Leaving them behind will cause syntax errors.
For simple conflicts, GitHub's web editor is the easiest solution. When a pull request has conflicts, GitHub shows a message: "This pull request has conflicts that must be resolved." Click the "Resolve conflicts" button to open the web editor.
In the web editor, you'll see the conflict markers highlighted. Edit the file to keep the correct version, remove the conflict markers, and click "Mark as resolved." Repeat for all conflicted files, then click "Commit merge" to complete the resolution. GitHub will commit the resolved changes directly to your branch.
Steps to resolve in GitHub web editor:
1. Go to the Pull Request
2. Click "Resolve conflicts" button
3. Edit each conflicted file
4. Remove conflict markers (<<<<<<, ======, >>>>>>)
5. Click "Mark as resolved" for each file
6. Click "Commit merge"
The command line gives you full control over conflict resolution. First, run git status to see which files have conflicts. Git marks them as "both modified" or "unmerged." Open each conflicted file in your text editor, find the conflict markers, and edit to keep the correct version.
After editing a file, remove the conflict markers and save. Then run git add to stage the resolved file. Once all conflicts are resolved and staged, run git commit to complete the merge. Git will open an editor with a pre-filled merge commit message—save and close to finish.
# Check which files have conflicts
$ git status
On branch feature-branch
You have unmerged paths.
both modified: src/app.js
# Open the file and fix conflicts manually
$ code src/app.js
# After fixing, stage the resolved file
$ git add src/app.js
# Commit the merge resolution
$ git commit -m "Merge: resolved conflicts in app.js"
git mergetool to launch a visual merge tool from the command line. Git can open tools like VS Code, Vimdiff, or Kaleidoscope to help resolve conflicts visually.
VS Code has an excellent built-in merge editor that makes conflict resolution visual and intuitive. When you open a conflicted file in VS Code, you'll see "Accept Current Change," "Accept Incoming Change," and "Accept Both Changes" buttons. You can also edit the result directly in the bottom pane.
The inline merge editor shows three panes: the current branch's version (left), the incoming branch's version (right), and the result (bottom). You can click buttons to accept one side or the other, or manually edit the result. After resolving, save the file and stage it with git add.
# Configure VS Code as Git's merge tool
$ git config --global merge.tool vscode
$ git config --global mergetool.vscode.cmd "code --wait $MERGED"
# Launch merge tool for conflicted files
$ git mergetool
Keep your changes (theirs vs ours). When resolving a conflict, you have three options: keep your version, keep the incoming version, or combine both. For simple conflicts, choose one version. For more complex situations, you might need to manually edit to merge the changes.
Abort the merge. If the conflict is too complex or you're not ready to resolve, you can abort the merge entirely. Use git merge --abort to cancel the merge and return to your pre-merge state. This is useful when you need to communicate with your team before resolving.
Use a merge driver for specific file types. For binary files (images, PDFs) or generated files, you can configure Git to always keep one side or use a custom merge tool. This prevents conflicts on files that shouldn't be merged automatically.
# Abort a merge and go back
$ git merge --abort
# Keep your version for all conflicts in a file
$ git checkout --ours -- src/file.js
$ git add src/file.js
# Keep the incoming version
$ git checkout --theirs -- src/file.js
$ git add src/file.js
Scenario 1: Same line changed in both branches. This is the most common conflict. Git shows both versions with conflict markers. Choose which version to keep, or combine them if appropriate.
Scenario 2: One branch deleted a file, the other modified it. Git marks this as a conflict. Decide whether to keep the modified file or respect the deletion. Use git rm to delete or git add to keep.
Scenario 3: Both branches added a file with the same name. Git can't decide which to keep. You'll need to manually merge the files or rename one.
Scenario 4: Whitespace conflicts. Different indentation or line endings can cause conflicts. Use git diff --ignore-space-change to see if only whitespace differs. Consider standardizing formatting across the team.
# Handle deleted vs modified conflict
# Keep the modified version (ignore deletion)
$ git add file.js
# Accept the deletion
$ git rm file.js
# Compare ignoring whitespace
$ git diff --ignore-space-change
Pull frequently. Before starting work, pull the latest changes from the main branch. During work, pull regularly to integrate changes early when conflicts are small.
Keep branches short-lived. Long-lived branches accumulate many changes and increase conflict risk. Merge feature branches back to main within a few days.
Communicate with your team. If multiple people are working on the same files, coordinate to avoid overlapping changes. Use feature flags or code ownership conventions.
Rebase before merging. Rebasing your feature branch on main before merging can resolve conflicts earlier and keep history linear. However, never rebase shared branches.
# Rebase feature branch on main before merging
$ git checkout feature-branch
$ git fetch origin
$ git rebase origin/main
# Resolve any conflicts during rebase
$ git add .
$ git rebase --continue
git add . followed by git rebase --continue. Use git rebase --abort to cancel the rebase.git checkout --ours or git checkout --theirs to select a version, then git add to stage it.git diff --merge to see differences between the conflicted file and both parents. git log --merge shows commits that caused the conflict.Merge conflicts are a normal part of Git collaboration. With practice and the right tools, you'll resolve them quickly and confidently.