git rebase — Rewriting History

Rebase takes your commits and replays them on top of another branch tip. Unlike merge, no merge commit is created — history is rewritten to appear linear. The golden rule: never rebase commits already pushed to a shared branch.

01.Rebase vs Merge: When to Use Which

Merge preserves exact history — branch divergences and merge commits are visible. Rebase rewrites history — your commits appear to have always been on top of the latest main, creating a clean linear log. Use rebase for keeping your feature branch up-to-date with main before a PR. Use merge for integrating completed PRs to preserve the full history.

Branch Visualization

main

feature

HEAD

02.Interactive Rebase: The History Superpower

git rebase -i (interactive) lets you rewrite the last N commits before they are shared. Operations: pick (keep as is), squash (meld into previous commit), fixup (squash silently), reword (edit the message), reorder (drag lines), drop (delete entirely). Use this to clean up "WIP" and "fix typo" commits into professional history before opening a PR.

Commit Timeline

a1b2c3d

init

b2c3d4e

feat

c3d4e5f

fix

d4e5f6a

HEAD

Commands

commands — click to reveal output

git checkout feature/login

Switch to your feature branch

git rebase main

Replay feature commits on top of the latest main

▼ show output

git rebase -i HEAD~4

Interactively edit the last 4 commits

# Change "pick" to "squash" to combine commits

squash | fixup | reword | drop | reorder

git rebase --continue

Continue after resolving a conflict mid-rebase

git rebase --abort

Cancel the rebase and restore original state

git push --force-with-lease

Push after rebasing (rewrites remote history — use with care)

KNOWLEDGE CHECK

When should you NEVER use git rebase?

Rate this lesson:

Previous Next Lesson