Merging vs Rebasing

Back to the novel analogy: you photocopied the manuscript, rewrote chapter 3 on the copy, and it worked out great. Now you need to get that rewrite back into the master copy. You have two honest ways to do it: staple the copy's chapter 3 into the master and note "chapter 3 was replaced on this date" (a merge), or carefully retype the rewrite in-place as if you'd written it there from the start, so the master reads as one clean draft (a rebase). Git gives you both options, and they solve the same problem with a different trade-off.

Merging: honest, if a little messy

git switch main
git merge feature/login-form

If main hasn't moved since you branched, this is a "fast-forward" merge — Git just slides the main pointer forward, no new commit needed. But if both branches have new commits, Git creates a merge commit: a special commit with two parents, one from each branch, stitching the two histories together. Nothing is rewritten; every commit that ever existed on either branch is still there, in the order it really happened.

Rebasing: rewriting for a straight line

git switch feature/login-form
git rebase main

This takes every commit unique to feature/login-form and replays it, one by one, on top of the current tip of main — as if you'd started your branch from there in the first place. The result is a clean, linear history with no merge commits. The catch: those replayed commits are technically brand-new commits (new hashes), even though the changes look the same. The originals are effectively discarded.

When to use which

• Use merge when combining a finished feature branch into main, or whenever the branch is shared with others — it's non-destructive and keeps the true story of what happened.
• Use rebase to tidy up your own local branch before sharing it — for example, pulling in the latest main so your feature branch applies cleanly on top, without a tangle of unrelated merge commits in your personal history.

Merge conflicts: when Git needs your judgment

Both merging and rebasing can hit a conflict — when the same lines of a file were changed differently on both sides, and Git can't guess which version is right. Git pauses and marks the file:

<<<<<<< HEAD
const greeting = "Hello there!";
=======
const greeting = "Hi, welcome!";
>>>>>>> feature/login-form

Resolving it means editing the file to keep the version you want (or a blend of both), removing the <<<<<<< / ======= / >>>>>>> markers entirely, then telling Git it's resolved:

git add greeting.js
git commit    # finishes a merge conflict
# or, mid-rebase:
git rebase --continue

If a conflict looks too tangled to sort out, you can always back out cleanly:

git merge --abort
git rebase --abort

git switch -c branch-a
echo "Version A" > note.txt
git add note.txt && git commit -m "Write version A"

git switch main
echo "Version B" > note.txt
git add note.txt && git commit -m "Write version B"

git merge branch-a

Next up: none of this matters much until your work leaves your laptop. Time to look at remotes and how collaboration actually works with GitHub.