Skip to content

Rebase

One-liner

Git rebase replays your branch's commits on top of another branch, creating a clean linear history.

Why it matters

Merge commits clutter the log and make git bisect and git log harder to use. Rebase keeps your history a straight line — every commit tells a clear, sequential story that future developers (including you) can follow without untangling merge bubbles.

Core concept

Think of rebase like cutting a row of photos from a scrapbook and re-gluing them at the end of a different page. The photos (commits) don't change in content — they just get a new position in the timeline. The page they were originally on disappears because there's nothing left on it.

In git terms: rebase takes commits from your branch, temporarily removes them, fast-forwards your branch to the tip of the target, then re-applies each commit one by one on top.

How it works

  1. Identify the divergence point — git finds the common ancestor between your branch and the target branch.
  2. Save your commits — git stores your branch's unique commits as patches in a temporary area.
  3. Reset to target — your branch pointer moves to the tip of the target branch (e.g., origin/main).
  4. Replay commits — each saved commit is re-applied in order on top of the new base.
  5. Resolve conflicts per commit — if a commit conflicts, you fix it and git rebase --continue; git moves to the next commit.

Key terms

  • Rebase — rewriting commit history by changing the base (parent) of a series of commits
  • Interactive rebase (git rebase -i) — lets you squash, reorder, edit, or drop commits before replaying
  • Force push (git push --force-with-lease) — required after rebase since commit SHAs change; --force-with-lease adds safety by refusing if the remote changed
  • Fast-forward — when the target hasn't moved, git just advances the pointer without creating a merge commit
  • Squash — combining multiple commits into one during interactive rebase

Common misconceptions

  • "Rebase deletes commits" — No. It creates new commits with the same changes but different SHAs. The originals remain in the reflog for 30+ days.
  • "Rebase and merge are interchangeable" — They serve different purposes. Rebase linearizes history; merge preserves the branching structure. Use rebase to update your branch, merge to integrate it.
  • "Never rebase" — The rule is narrower: never rebase commits that others have based work on. Rebasing your own unpushed or solo-branch commits is safe and encouraged.

When to use / not use

✓ Use when: updating your feature branch with latest main, cleaning up commits before a pull request, keeping history linear for easier navigation and bisecting.

✗ Don't use when: the branch is shared and others have commits on top of yours, you need to preserve exact merge history for auditing, or the team convention is merge-based workflow.

Example

# Update feature branch with latest main
git fetch origin
git rebase origin/main

# Clean up last 3 commits interactively
git rebase -i HEAD~3

# After rebase, force push safely
git push --force-with-lease

Next steps

  1. Practice interactive rebase (git rebase -i) on a throwaway branch to build muscle memory
  2. Learn git rerere for automatically reusing conflict resolutions across repeated rebases
  3. Explore git rebase --onto for transplanting a branch to a completely different base