Working Like an Engineer: Git, PRs & Code Review · Lesson 2 of 6 · Bonus module

Your First Merge Conflict

A conflict isn't an error. It's git refusing to guess between two truths — yours and main's — and asking a human to decide.

By Shahriyar · Updated

Why it happens

While you worked on your branch, someone changed the same lines on main. Git can merge changes to different places silently; the same place needs you.

▸ What a conflict actually looks like
<<<<<<< HEAD
  await page.click("#place-order");
=======
  await page.getByRole("button", { name: "Place order" }).click();
>>>>>>> main

# resolve: keep one (or combine), DELETE the marker lines, then
git add checkout.spec.js
git rebase --continue   # or: git commit, if you were merging

Rebase vs merge — why teams argue

Merge keeps history as it happened, with extra merge commits. Rebase replays your commits on top of main — linear and clean, but it rewrites your branch. Both are correct; teams pick one. Asking "do we rebase or merge here?" on day one reads as experience, not ignorance.

Grounded in the git documentation on merging and rebasing

All lessons in Working Like an Engineer: Git, PRs & Code Review

  1. The Loop: Branch, Commit, PR, Merge
  2. Your First Merge Conflict
  3. Reading Code You Didn't Write
  4. Receiving a Review Without Taking It Personally
  5. Giving a Review as the Quality Person
  6. Commits and PRs an Interviewer Will Read