Resolving Conflicts: Manual Resolution and Using VS Code / IntelliJ Merge Tools

Once you understand what conflict markers mean (previous lesson), resolving them is a methodical, learnable process. This lesson walks through the complete manual resolution workflow from start to finish, then shows how visual merge tools built into editors like VS Code and IntelliJ streamline the exact same underlying task with a friendlier interface.

Learning Objectives

• Manually edit a conflicted file to resolve conflict markers correctly.
• Stage and commit a resolved conflict to complete the merge.
• Use VS Code's built-in conflict resolution buttons (Accept Current/Incoming/Both).
• Understand IntelliJ's three-pane merge tool layout.

Key Terms to Know Before Learning Resolving Conflicts

• Conflict resolution: The process of editing a conflicted file to remove conflict markers and decide on the final, correct content.
• Accept Current Change: An IDE action that keeps only the version from your current branch (HEAD), discarding the incoming version.
• Accept Incoming Change: An IDE action that keeps only the version from the branch being merged in, discarding your current version.
• Accept Both Changes: An IDE action that keeps both competing versions, typically stacked one after another, requiring further manual cleanup.
• Three-pane merge view: A layout (common in IntelliJ and similar tools) showing 'yours' on one side, 'theirs' on the other, and the merged result in the middle, all editable simultaneously.

How Resolving Conflicts Actually Works

**Manual resolution**, without any special tooling, follows a clear sequence:

1. Open the conflicted file in any text editor and locate each conflict block (`<<<<<<<` ... `=======` ... `>>>>>>>`).
2. Decide on the correct final content — this might mean keeping only your version, only the incoming version, a combination of both, or something entirely new that reconciles the intent of both changes.
3. Edit the file to contain exactly that final content, and **delete all three marker lines** (`<<<<<<<`, `=======`, `>>>>>>>`) entirely — leaving any of them in place will cause the file to contain invalid, broken content.
4. Repeat for every conflict block in every affected file.
5. Stage the resolved file(s) with `git add <file>` — this is how you tell Git 'this conflict is resolved.'
6. Once every conflicted file has been staged, run `git commit` (no `-m` needed; Git pre-populates a merge commit message you can accept or edit) to finalize the merge.

```
git add app.js
git commit
```

This process works for any conflict, in any file type, using only a plain text editor — it's the foundational skill underlying every fancier tool.

**VS Code's built-in conflict resolution** streamlines this considerably. When VS Code detects conflict markers in an open file, it displays inline buttons directly above each conflict block: **Accept Current Change** (keep only your/HEAD's version), **Accept Incoming Change** (keep only the other branch's version), **Accept Both Changes** (keep both, stacked, letting you manually clean up further if needed), and **Compare Changes** (view a side-by-side diff for that specific block). Clicking one of these buttons automatically removes the conflict markers and leaves only the chosen content — after resolving all blocks in a file this way, you still need to `git add` and `git commit` to finalize the merge, exactly as in the manual process.

**IntelliJ's merge tool** (and similar JetBrains IDEs) takes a different visual approach: a **three-pane view** showing 'Yours' (your current branch's version) on the left, 'Theirs' (the incoming branch's version) on the right, and the actual **Result** (merged output) in a resizable pane in the middle. You can click small arrow icons next to each conflicting change to accept it from the left, the right, or manually edit the result pane directly — giving you fine-grained, visual control over exactly how each section is reconciled. Once every conflict in the file is resolved in the result pane, saving it and returning to your terminal (or IntelliJ's own Git integration) to stage and commit completes the merge, just as in the manual and VS Code workflows.

Regardless of which method you use, the underlying steps are identical: **decide the correct content for each conflict, remove the markers, stage the file, and commit to complete the merge.** Tools only change how comfortably and visually you make that decision — they don't change what Git itself requires to consider the conflict resolved.

Resolving Conflicts: Visual Walkthrough

Draw a horizontal five-step process flow: 1) 'Conflict detected — markers inserted in file' → 2) 'Open file (in plain editor, VS Code, or IntelliJ)' → 3) 'Decide correct content for each block (keep current / incoming / both / rewrite)' → 4) 'Remove ALL marker lines (<<<<<<<, =======, >>>>>>>)' → 5) 'git add <file> then git commit — merge complete'. Beneath, show two small tool icons: 'VS Code: inline Accept Current/Incoming/Both buttons' and 'IntelliJ: three-pane Yours | Result | Theirs view', both feeding into the same step 4-5 sequence.

Resolving Conflicts: Quick Reference Table

Method	How Content Is Chosen	Still Requires git add + commit?
Manual (plain text editor)	Directly edit file, delete markers by hand	Yes
VS Code inline buttons	Click Accept Current / Incoming / Both	Yes
IntelliJ three-pane tool	Click arrows to pull from Yours/Theirs, or edit Result pane directly	Yes
git mergetool (any configured external tool)	Varies by configured tool	Yes (covered in the next lesson)

Resolving Conflicts: Command Syntax and Examples

# --- Manual resolution ---
# 1. Open app.js and find the conflict block:
# <<<<<<< HEAD
# const greeting = "Hello there!";
# =======
# const greeting = "Welcome!";
# >>>>>>> feature/dark-mode

# 2. Decide, edit, and remove ALL marker lines, e.g., keeping a combined result:
# const greeting = "Hello there! Welcome!";

# 3. Stage the resolved file
git add app.js

# 4. Confirm no unresolved conflicts remain
git status
# All conflicts fixed but you are still merging.
#   (use "git commit" to conclude merge)

# 5. Complete the merge
git commit
# (opens editor with a pre-filled merge commit message — accept or edit it)

Breaking Down the Resolving Conflicts Example

This walkthrough shows the complete manual process: identifying the conflict block, deciding on a resolution (here, combining both greetings into one), and critically removing every marker line so the file contains only valid, working content. `git add app.js` marks this specific file's conflict as resolved. `git status` confirms the encouraging message 'All conflicts fixed but you are still merging', explicitly telling you the remaining step. `git commit` (without `-m`) opens the pre-populated merge commit message for review, and accepting or editing it finalizes the merge — completing exactly the same underlying requirement that VS Code's buttons or IntelliJ's three-pane tool would also ultimately need in order to finish.

How Resolving Conflicts Is Used on Real Engineering Teams

• Professional developers frequently switch fluidly between manual resolution and IDE tools depending on the complexity of a conflict — trivial ones are often fixed faster by hand, while complex, multi-section conflicts benefit greatly from a visual tool.
• Code review culture at many companies expects a clear, deliberate commit message on merge commits explaining how a non-trivial conflict was resolved, especially when the resolution required judgment calls beyond simply picking one side.
• IntelliJ's three-pane merge tool is particularly popular among Java, Kotlin, and enterprise backend teams, where JetBrains IDEs are the dominant development environment.
• VS Code's inline conflict buttons have become extremely popular in web development and JavaScript/TypeScript-heavy teams, given VS Code's dominant market share in that ecosystem.

Resolving Conflicts Interview Questions and Answers

Q1. What are the essential steps to resolve a merge conflict manually?

Open the conflicted file, locate each conflict block delimited by <<<<<<<, =======, and >>>>>>>, decide on the correct final content, and edit the file so that all three marker lines are completely removed, leaving only valid, working content. Then stage the resolved file with git add, and once every conflicted file is staged, run git commit to finalize the merge.

Q2. What do VS Code's 'Accept Current Change' and 'Accept Incoming Change' options do?

'Accept Current Change' keeps only the version of the content from your current branch (HEAD), discarding the other side. 'Accept Incoming Change' does the opposite, keeping only the version from the branch being merged in. Both automatically remove the surrounding conflict markers, but you still need to stage and commit afterward to complete the merge.

Q3. How does IntelliJ's merge tool present a conflict differently from a plain text editor?

It shows a three-pane view: 'Yours' (your current branch's version) on one side, 'Theirs' (the incoming branch's version) on the other, and an editable 'Result' pane in the middle showing the merged output. You can pull specific changes from either side into the result, or edit the result pane directly, giving fine-grained visual control over the resolution.

Resolving Conflicts Quiz: Test Your Understanding

1. What must you do to every conflict marker line during resolution, regardless of method?

1. Leave them in place as documentation
2. Remove them completely once the correct content is decided
3. Convert them into code comments
4. Copy them into the commit message

Answer: B. Remove them completely once the correct content is decided

Explanation: Conflict markers are not valid code or content — every marker line (<<<<<<<, =======, >>>>>>>) must be deleted, leaving only the final, correct resolved content behind.

2. After resolving conflicts in all affected files, what two Git commands are still required to complete the merge?

1. git branch and git switch
2. git add <file> and git commit
3. git clone and git push
4. git tag and git archive

Answer: B. git add <file> and git commit

Explanation: Regardless of whether resolution was done manually or with an IDE tool, each resolved file must be staged with git add, and git commit finalizes the merge once all conflicts are staged.

3. In IntelliJ's merge tool, what does the middle pane represent?

1. An unrelated, unmodified copy of the file
2. The editable, final merged 'Result'
3. A read-only diff summary
4. The commit history of the file

Answer: B. The editable, final merged 'Result'

Explanation: IntelliJ's three-pane layout places the actual merged output — the Result — in the middle, editable directly or by pulling specific changes in from the 'Yours' and 'Theirs' panes on either side.

Resolving Conflicts: Common Mistakes Beginners Make

• Forgetting to remove all three types of conflict markers, leaving invalid content (like a stray ======= line) in the final file, which breaks compilation or execution.
• Believing that clicking a resolution button in VS Code or IntelliJ automatically completes the merge — git add and git commit are still required afterward.
• Resolving a conflict by simply picking one side without genuinely considering whether the correct fix actually needs to combine or rewrite both versions.
• Not re-checking git status after resolving all visible conflicts, potentially missing an additional conflicted file that still needs attention.

Resolving Conflicts: Exam-Ready Quick Notes

• Manual resolution: edit file, decide correct content, remove ALL marker lines, git add, git commit.
• VS Code: inline Accept Current/Incoming/Both buttons remove markers automatically; still requires add + commit.
• IntelliJ: three-pane view (Yours | Result | Theirs); still requires add + commit after resolving in the Result pane.
• No matter the tool used, git add + git commit are always required to finalize a merge after conflicts are resolved.

Resolving Conflicts: Key Takeaways

• Resolving a conflict fundamentally means deciding on correct final content and completely removing Git's conflict markers, regardless of which tool is used.
• VS Code and IntelliJ both provide visual, convenience-focused ways to make that same decision more comfortably, but neither replaces the final git add and git commit steps.
• Building comfort with manual, plain-text resolution first makes any IDE-based tool feel like a natural convenience rather than a mysterious black box.

Frequently Asked Questions About Resolving Conflicts

Q1. What is the basic process for resolving a merge conflict by hand?

Open the conflicted file, find each block marked by <<<<<<<, =======, and >>>>>>>, decide what the final correct content should be, edit the file so that content is correct and every marker line is removed, then stage the file with git add and run git commit to finish the merge.

Q2. Do I still need to run git add and git commit if I use VS Code's conflict resolution buttons?

Yes. VS Code's Accept Current/Incoming/Both buttons only handle deciding the content and removing the markers for you — you still need to stage the resolved file with git add and run git commit to actually complete the merge.

Q3. What does IntelliJ's three-pane merge view show?

It shows 'Yours' (your current branch's version) on one side, 'Theirs' (the incoming branch's version) on the other, and an editable 'Result' pane in the middle representing the final merged content, which you can build by pulling changes from either side or editing directly.

Q4. What happens if I forget to remove a conflict marker line before committing?

The file will contain invalid content (like a leftover ======= line), which will typically break your code's compilation or execution. Always double-check that every marker has been removed before staging and committing a resolved file.

Q5. Is one method of resolving conflicts (manual, VS Code, IntelliJ) more 'correct' than the others?

No. They all accomplish exactly the same underlying task — deciding the correct content and removing conflict markers. The choice mostly comes down to personal preference and the complexity of the conflict; all methods still require the same final git add and git commit steps.

Summary

Resolving a merge conflict, regardless of method, always follows the same underlying steps: decide on the correct final content for each conflicting section, completely remove Git's conflict markers (`<<<<<<<`, `=======`, `>>>>>>>`), stage the resolved file with `git add`, and run `git commit` to finalize the merge. Manual resolution does this directly in a plain text editor. VS Code streamlines the decision-making with inline 'Accept Current Change', 'Accept Incoming Change', and 'Accept Both Changes' buttons that automatically remove the markers for you. IntelliJ offers a three-pane visual merge tool ('Yours', 'Result', 'Theirs') for fine-grained control. In every case, `git add` and `git commit` remain the required final steps to actually complete the merge.