Don’t Panic: A Hands‑On Guide to Resolving Git Conflicts

Understanding Git Conflicts

When two developers edit the same line of a file on different branches, Git cannot automatically decide which change to keep, so it stops the merge and inserts conflict markers, prompting manual resolution.

Why Conflicts Happen

Example: the original code contains const timeout = 3000;. On branch feature/login the line is changed to const timeout = 5000;, while on main it is changed to const timeout = 2000;. Merging main into feature/login produces a conflict because the same line has two different values.

Reading Conflict Markers

Git inserts the following markers in the file:

<<<<<<< HEAD
const timeout = 3000;
=======
const timeout = 5000;
>>>>>>> feature/login

Everything between <<<<<<< HEAD and ======= is the current branch’s content; the section after ======= up to >>>>>>> feature/login is the incoming change.

Standard Conflict‑Resolution Workflow

Run git status to list conflicted files.

Open each file, locate the <<<<<<< markers, and edit the code to keep the correct version or rewrite a new one.

After editing, stage the file with git add ..

If you are in a merge, finish with git commit; if you are in a rebase, continue with git rebase --continue.

To abort the operation, use git merge --abort or git rebase --abort respectively.

Three Common Resolution Strategies

Keep current branch (HEAD) : discard the incoming change.

Keep incoming branch : discard the current change.

Rewrite : discard both and write a new implementation that fits the business logic (e.g., change const timeout = 3000; and const timeout = 5000; to const timeout = 4000;).

Using IDE Tools

Many IDEs (VS Code, IntelliJ IDEA, WebStorm) provide visual conflict‑resolution panels with buttons such as “Accept Current Change”, “Accept Incoming Change”, “Accept Both Changes”, and “Compare Changes”. These shortcuts help you pick the desired side, but you must still understand which side corresponds to which branch and the business impact of the change.

Post‑Resolution Checklist

Run the relevant test suite (e.g., npm test or pnpm test).

Manually verify key functionality in the module you just merged.

Inspect the final diff with git diff --cached to ensure no unintended changes remain.

Search for leftover conflict markers: git grep "<<<<<<<". Any output indicates unresolved markers.

Tips to Reduce Future Conflicts

Synchronize with the latest main before starting work: git pull origin main.

Keep feature branches short; the longer a branch lives, the larger the divergence.

Limit each branch to a single concern; avoid mixing unrelated changes (e.g., don’t edit payment logic while working on login).

Avoid large, unrelated formatting changes that increase merge friction.

Review the diff before committing: git diff.

Command Cheat Sheet

git status          # view conflicted files
git diff            # view un‑staged conflict content
git add .           # mark conflicts as resolved
git commit          # finalize a merge
git rebase --continue   # continue a rebase after resolution
git merge --abort      # abort the current merge
git rebase --abort     # abort the current rebase
git grep "<<<<<<<"   # check for leftover markers

Conclusion

Git conflicts are not accidents but signals that multiple changes compete for the same code. The real risk lies in merging without understanding the markers. By following the systematic workflow, choosing the appropriate resolution strategy, and performing thorough post‑merge checks, you keep the main branch stable and avoid hidden bugs.