How to Fix a Merge Conflict in VS Code Step by Step

You pull the latest code or merge a branch, and suddenly VS Code fills with strange symbols, red highlights, and a file you cannot run anymore. Git stops and tells you there is a merge conflict. For beginners, this is one of the most stressful moments in coding.

Take a breath. A merge conflict is not an error or a failure. It simply means two versions of the same lines were changed in different ways, and Git needs a human, you, to choose the final version. VS Code has a friendly built-in tool for exactly this, and this guide walks you through it slowly, step by step.

Quick Answer

To fix a merge conflict in VS Code, open the conflicted file from the Source Control panel, review the highlighted Current and Incoming changes, and click Accept Current Change, Accept Incoming Change, or Accept Both Changes above each conflict block. When no conflict markers remain, save the file, stage it, and complete the merge with a commit. VS Code’s Merge Editor can also show the two versions side by side with a live result preview.

What Is a Merge Conflict, in Simple Words?

Imagine you and a friend both edit the same paragraph in a shared document at the same time, but you write different sentences. When the copies are combined, no program can honestly know which sentence you both want to keep. Someone has to decide.

Git faces the same problem with lines of code. If you changed line 20 on your branch, and a teammate changed the same line 20 on their branch, merging creates a conflict. Git protects both versions, marks the exact spot in the file, and pauses the merge until you resolve it.

Conflicts most often happen in three situations: merging a branch into another branch, pulling changes that touch the same lines you edited, and rebasing your work onto newer code. Busy shared files like configuration files, package lists, and the top of a homepage are classic conflict hotspots because everyone touches them.

What the Conflict Markers Mean

When you open a conflicted file as raw text, you will see markers like these:

• <<<<<<< HEAD — the start of your current branch’s version.
• ======= — the divider between the two versions.
• >>>>>>> branch-name — the end of the incoming version, from the branch being merged in.

Everything between the first marker and the divider is the Current Change, which is your side. Everything between the divider and the last marker is the Incoming Change, which is their side. The goal of resolving is to produce one clean final version and delete every single marker. A file that still contains any marker is not resolved, and it will not run correctly.

Step by Step: Fixing a Conflict in VS Code

Step 1: See Which Files Are Conflicted

1. Open the Source Control panel in VS Code with Ctrl + Shift + G on Windows or Cmd + Shift + G on Mac.
2. Look for a Merge Changes section. Files listed there with a warning icon are the conflicted ones.
3. You can also run git status in the terminal. Conflicted files appear under Unmerged paths.

Work through conflicted files one at a time. Trying to hold three files in your head at once is how mistakes happen. Finish one, save it, then move on.

Step 2: Open the File and Read the Conflict

1. Click a conflicted file to open it in the editor.
2. Scroll to the highlighted block. VS Code colors the Current Change and the Incoming Change differently so you can compare them.
3. Read both versions carefully before clicking anything. Ask yourself what each version was trying to do.

Step 3: Choose an Option for Each Conflict Block

Directly above each conflict block, VS Code shows small clickable actions:

• Accept Current Change: keep only your branch’s version.
• Accept Incoming Change: keep only the other branch’s version.
• Accept Both Changes: keep both, yours first, then theirs. Check the order makes sense afterwards.
• Compare Changes: opens a side-by-side view when you need a closer look.

1. Click the option that matches the correct final code.
2. Check the result immediately. If none of the one-click options give exactly what you need, edit the text by hand. You are allowed to type anything here, delete lines, and blend both versions into a better third version.
3. Move to the next conflict block in the same file and repeat until no markers remain anywhere in the file.

Manual editing is not cheating, it is often the most correct answer. For more everyday editor confidence while you work, our collection of practical VS Code tips for beginner developers covers the Source Control panel and shortcuts in more depth.

Step 4: Try the Visual Merge Editor for Hard Conflicts

For a messy conflict, VS Code offers a dedicated Merge Editor with three panes: your version, their version, and the result being built at the bottom.

1. When you open a conflicted file, look for a button at the bottom right that says Resolve in Merge Editor, and click it.
2. Use the checkboxes next to each change to accept the pieces you want from each side.
3. Watch the Result pane update live. Edit it directly if something still looks wrong.
4. Click Complete Merge when the result is correct.

Step 5: Test Before You Declare Victory

1. Save the file with Ctrl + S or Cmd + S.
2. Search the whole project for <<<<<<< using Ctrl + Shift + F. Zero results means no markers are hiding anywhere.
3. Run the project, or at least open the changed pages and run any quick tests you have. A conflict can be textually resolved but logically wrong, for example if you kept a variable rename from one side but old usages from the other.

Step 6: Stage and Complete the Merge

1. Back in the Source Control panel, click the plus icon next to the resolved file to stage it. Staging is how you tell Git, this conflict is resolved.
2. Repeat resolving, saving, and staging for every conflicted file until git status shows no Unmerged paths.
3. VS Code will pre-fill a merge commit message. Accept it and commit to finish the merge.
4. Push with git push so your team gets the resolved result.

Until that final commit, you are still in the middle of a merge. Do not start new feature work halfway through. Finish, commit, and then move on with a clean state.

Common Mistakes to Avoid

• Blindly accepting one side everywhere. Choosing Current for the whole file can silently delete a teammate’s entire feature. Read each block.
• Leaving conflict markers in the file. Even one leftover ======= line breaks the file. Always search the project before committing.
• Forgetting to test after resolving. A file can look clean and still be logically broken. Run the code.
• Accepting Both without checking order. Both does not always mean correct. Duplicated imports and repeated code are common results of careless Both choices.
• Resolving a conflict you do not understand by guessing. If a block belongs to a teammate’s work and you cannot tell what it does, ask them. A two-minute question beats a two-hour bug.
• Committing before every file is resolved. Git will block a merge commit with unresolved paths, but partial staging creates confusion. Resolve all, stage all, then commit once.

Conclusion

Merge conflicts feel alarming the first time, but the process in VS Code is calm and methodical: open the file from Source Control, read the Current and Incoming versions, accept or hand-blend the right code for each block, search for leftover markers, test, stage, and commit. Use the Merge Editor for tough cases, and use git merge --abort whenever you need to step back safely. After you have resolved a few conflicts this way, they stop being scary and become a normal, even satisfying, part of teamwork with Git.

Frequently Asked Questions

Why did I get a merge conflict if I am working alone?

Solo developers get conflicts too, usually when the same lines were changed on two of your own branches, or when you edited files both on GitHub’s website and locally. Git compares changes, not people, so any two edits to the same lines that cannot be combined automatically will conflict, whatever their source.

Can VS Code resolve conflicts automatically?

VS Code and Git already auto-resolve everything that can be combined safely, such as edits in completely different parts of a file. What remains truly needs a human decision, so there is no fully automatic fix for a real conflict. The editor’s buttons and Merge Editor simply make that human decision fast and visual, as described in the GitHub guide to resolving merge conflicts.

What if I resolved a file wrong? Can I start that file over?

Yes, while the merge is still in progress you can run git checkout --merge filename to restore the conflict markers in that file and resolve it again from scratch. If you already committed the bad resolution, it is usually easier to just make a new normal commit that fixes the file contents.

What does Accept Current Change mean during a pull versus a merge?

Current always means the branch you are standing on, and Incoming means the changes coming in. During a git pull, Current is your local branch and Incoming is the remote version. During a rebase, the labels can feel reversed because Git applies your commits on top of the other branch, so read the branch names shown next to each block carefully.

How can I reduce how often conflicts happen?

Pull often, keep branches short-lived, and make smaller, focused commits. Communicate with teammates about who is editing shared files, and avoid everyone reformatting the entire codebase at once, since formatting changes touch every line and conflict with everything. Small, frequent merges produce small, easy conflicts instead of giant scary ones.