Rebase vs Merge

The war between rebase and merge is a false one. They’re different tools for different situations.

What each one does

Merge (no fast-forward)
Rebase

gitGraph
   commit id: "A"
   commit id: "B"
   branch feature
   commit id: "F1"
   commit id: "F2"
   checkout main
   commit id: "C"
   merge feature id: "M"

Preserves the shape of history — you can see the branch existed.

gitGraph
   commit id: "A"
   commit id: "B"
   commit id: "C"
   commit id: "F1'"
   commit id: "F2'"

Rewrites your feature commits on top of the target. Linear history, but new SHAs.

The rule

Interactive rebase — cleaning up before PR

git fetch origin
git rebase -i origin/main

Then in the editor:

pick    a1b2c3  Add config parser
squash  d4e5f6  Fix typo
squash  g7h8i9  Fix another typo
reword  j0k1l2  WIP notes

Recovering from a bad rebase

Check git reflog — every ref update is logged for ~90 days.

git reflog
# a1b2c3d HEAD@{0}: rebase (finish): returning to refs/heads/feature
# e4f5g6h HEAD@{5}: commit: Add config parser

Reset back to the pre-rebase state.
Terminal window
```
git reset --hard HEAD@{5}
```
Force-push — but only if the branch is yours alone.
Terminal window
```
git push --force-with-lease origin feature
```

Merge strategies on the PR

Strategy	Best for	Downside
Squash and merge	Single-purpose PRs, keeps main linear	Loses per-commit context
Rebase and merge	Multi-commit PRs, linear history	Rewrites SHAs — CI must re-run
Merge commit	Long-lived feature branches with history	Adds merge nodes