Rebasing

Rebasing moves or replays your branch’s commits onto a different base commit, creating a linear history without merge commits.

Basic Rebase

git checkout feature
git rebase main

This takes all commits from feature and replays them on top of main. The result is a clean, linear history.

Visual Example

# Before rebase:
      C1---C2 (feature)
     /
A---B---C3 (main)

# After git rebase main on feature:
              C1'---C2' (feature)
             /
A---B---C3 (main)

The prime notation (C1’, C2’) indicates these are new commits with different hashes.

Interactive Rebase

git rebase -i HEAD~3

Opens an editor where you can reorder, squash, reword, or drop the last 3 commits:

pick a1b2c34 Add login form
pick d5e6f78 Fix typo
pick g9h0i12 Add validation

• pick — keep the commit as-is
• squash — merge into previous commit
• reword — change the commit message
• drop — remove the commit entirely

Rebase vs Merge

• Rebase: Linear history, clean log, rewrites commit hashes
• Merge: Preserves history, adds merge commit, safe for shared branches

When to Rebase

• Cleaning up feature branch history before merging
• Updating a feature branch with latest changes from main
• Squashing multiple small commits into meaningful ones
• Keeping a linear history for easier code review

Best Practices

• Use rebase on local/feature branches before merging
• Never rebase commits that are pushed to shared branches
• Run tests after a rebase to catch conflicts
• Keep rebase operations small and focused

Common Mistakes

• Rebasing a branch that others are working on
• Using interactive rebase on too many commits at once
• Forgetting that rebase changes commit hashes
• Resolving conflicts incorrectly during a rebase
• Pushing a rebased branch without force-pushing (requires --force-with-lease)