Git Course 0%

Resolve in VS Code, IntelliJ, GitLab, GitHub

Intermediate VS Code UI IntelliJ UI GitLab UI GitHub UI ≈ 15 min

What you will learn

  • How VS Code's inline actions and merge editor map onto the terminal steps
  • How IntelliJ's three-pane merge tool works and what its buttons do
  • What GitLab and GitHub can and cannot resolve in the browser

After this lesson you can

  • I can resolve a conflict in whichever tool I have open, and know when to go back to the terminal

Why this matters

Graphical merge tools are genuinely better than editing markers by hand, especially for a long conflict, because they show both sides side by side and let you click. They are also the place where people get lost, because the buttons have names like "ours" and "theirs" without saying which is which. This lesson maps every button onto the four steps you already know from lesson 11.3.

The four steps, whatever the tool

Step Terminal VS Code IntelliJ
1. Find the files git status Source Control, Merge Changes group Files Merged with Conflicts dialog
2. Edit your editor inline actions or the merge editor the three-pane merge tool
3. Mark resolved git add <file> Complete Merge, or stage the file Apply Changes
4. Finish git commit Commit Commit

Nothing else is different. If a tool confuses you, drop to the terminal: the repository is in the same state either way.

How to do it

The reference procedure, from lesson 11.3:

Terminal
$ git status
$ # edit the file, delete every marker line
$ git add docs/faq.md
$ git commit --no-edit

Everything the graphical tools do reduces to these four steps, and you can switch between the terminal and a tool at any point in the middle.

Choosing a tool

Situation Best tool
One or two lines of prose inline actions in your editor, or the browser
A long conflict, several blocks VS Code merge editor or IntelliJ's merge tool
Many files at once IntelliJ's dialog with Apply All Non-Conflicting Changes
Binary file any tool's "take one side" option, or git checkout --ours/--theirs
Anything you need to test afterwards locally, in the terminal or an IDE

Common mistakes

  • Assuming "Current" and "Yours" mean your branch in every context. They do during a merge; during a rebase the sides are swapped (lesson 11.5). When unsure, read the actual text rather than the label.
  • Clicking "Accept Both" and committing. The result is often duplicated sentences or code that does not compile; read the Result pane.
  • Resolving code in the browser. Nothing is compiled or tested there.
  • Forgetting the remaining files. Tools resolve one file at a time; git status is the reliable list of what is left.
  • Leaving the merge editor without Complete Merge. The file may be edited but not staged, so the commit is refused.

Try it yourself

Goal: resolve the same conflict twice, once with a tool and once by hand.

  1. Create the FAQ conflict from lesson 11.1 and start the merge.
  2. Resolve it in your IDE: VS Code's merge editor or IntelliJ's merge tool. Note which pane is yours.
  3. Before committing, run git status in the terminal and confirm the file is staged.
  4. Abort with git merge --abort and create the conflict again.
  5. Resolve it by hand this time, with git add and git commit.

Expected result: both routes end in the same commit; step 3 shows the tool ran git add for you.

Show solution

Step 3 is the point: the graphical tool is a nicer front end to the same index. Once you have seen that its "done" button is git add, switching between the terminal and the tool mid-conflict stops feeling risky.

Check yourself

1. In VS Code's merge editor, which pane is the one that gets saved?
2. What does IntelliJ's Apply All Non-Conflicting Changes do?
3. When is resolving in the GitLab or GitHub browser editor a poor choice?

Key terms

Merge conflict Merge Merge request (MR)