Rebase — Explained with Examples

Rebase moves commits from one branch to a new base commit, creating a linear project history by replaying changes on top of another branch.

Rebasing takes the commits from your current branch and applies them onto the tip of another branch. Unlike merging, which creates a merge commit, rebase rewrites history by creating new commits for each original commit, resulting in a clean, linear timeline. Interactive rebase (git rebase -i) allows you to squash, reorder, edit, or drop commits during the process.

Think of rebase like revising a presentation. Instead of presenting your rough drafts in order (merge), you clean up each slide, remove the messy versions, and present only the polished final product (rebase). Squashing is like combining several small edits into one clean slide.

Rebasing is controversial because it rewrites history. A golden rule: never rebase commits that have been pushed to a shared branch. Rebasing public commits causes divergence for other developers who have based work on the original commits.

# Rebase feature branch onto main
git checkout feature/login
git rebase main

# Interactive rebase to squash last 3 commits
git rebase -i HEAD~3

# Output after successful rebase:
# Successfully rebased and updated refs/heads/feature/login.

Rebase keeps history tidy but demands discipline. Use it for cleaning up local commits before sharing; use merge for integrating shared branches.

Merge, Branch, Git, Cherry Pick

Merge vs Rebase