How to solve merge conflicts

Merge conflicts look scary the first time you see them: Git stops, dumps markers into your file, and refuses to continue. In reality a conflict just means "two changes touched the same lines and I need a human to decide." This guide walks through what a conflict is, how to read it, and how to resolve it confidently.

What a conflict actually is

A conflict happens when Git cannot automatically combine changes — usually because two branches edited the same region of a file. Git marks the conflicting area like this:

ts
<<<<<<< HEAD
const greeting = "Hello from main";
=======
const greeting = "Hello from feature";
>>>>>>> feature

• The part under `<<<<<<< HEAD` is your current branch's version.
• The part between `=======` and `>>>>>>> feature` is the incoming branch's version.
• Your job is to replace the whole block with the correct final result.

Step 1: Understand both sides before editing

Don't blindly keep one side. Read what each change does:

• Was one side a bug fix and the other a rename?
• Do both changes need to survive (e.g., different lines of a function)?
• Is one side stale and already superseded?

Step 2: Resolve the conflict

Edit the file to remove the markers and keep the right code:

ts
const greeting = "Hello from main";
const audience = "feature";

Then stage the resolved file:

bash
git add path/to/file.ts

Once all conflicts are resolved and staged, complete the merge or rebase:

bash
git commit        # for a merge
git rebase --continue   # for a rebase

Step 3: Verify the result

• Run the build and tests before pushing.
• Visually check the resolved region — it is easy to accidentally delete a line.
• Use `git diff` to confirm the final state is what you intended.

Tools that make it easier

• **VS Code** shows "Accept Current / Incoming / Both" buttons inline.
• **git mergetool** opens a 3-way merge editor (e.g., Meld, Beyond Compare).
• **git diff --ours / --theirs** previews each side.

bash
git config --global merge.tool vscode
git mergetool

How to avoid conflicts in the first place

• Pull/rebase often so branches stay close to main.
• Keep PRs small and focused.
• Communicate when touching shared files.
• Use feature flags instead of long-lived branches.

Conflicts are normal. Treat them as a decision point, not a disaster, and they become routine.