All commands

git rebase

advanced

Re-apply your commits on top of a new base — and rewrite history.

git rebase
Where this fits in the command map

What it does

git rebase takes your commits, lifts them off your branch's old base, and replays them onto the tip of another branch — one by one, as new commits. The result is a linear history. Because everything is re-created, every moved commit gets a brand-new hash.

before

a1b2c3dinit projecte4f5a6bmain: fix navmainc7d8e9ffeature: add btn0a1b2cdfeature: wire APIfeatureHEAD
git rebase main

after · linear

a1b2c3dinit projecte4f5a6bmain: fix navmainf1a2b3cfeature: add btn'b2c3d4efeature: wire API'featureHEAD

Each commit is re-created as a new object — h hashes rolled, history straight.

Watch it — press play

A narrated, step-by-step walkthrough that shows how to do it — not just theory. It adapts to the learner mode you picked in the top bar.

1 / 4

Step 1

Newer base, same ideas

You want your feature to sit on top of the newest main — not on a stale fork point.

git rebase main
a1b2c3dinit projecte4f5a6bmain: fix navmainc7d8e9ffeature: add btn0a1b2cdfeature: wire APIfeatureHEAD

feature grew from the old main

Under the hood

1

Old commits are recreated, not copied

Rebase finds the common ancestor, collects your commits up to the branch tip, then for each one: reads its tree and message, re-diffs it against the new base, and writes a BRAND-NEW commit object. Identical content, different parent — different hash.

before:
  main  ▸ a                   feature ▸ a — x — y

after:
  main  ▸ a — x — y                    (feature gone, replayed)
  feature ▸ a — x — y                  (x' and y' new hashes)
2

Every parent change rehashes the whole chain

Since a commit's hash depends on its parent, replacing the first parent re-rolls the hash of every descendant. That's why rebasing rewrites 'your' commits but never the branch you rebased onto.

3

The three-way apply per commit

For each commit, Git performs a mini three-way merge between the old base, your commit, and the new base. Conflicts pause the rebase so you can fix them before continuing.

4

Danger: you're editing shared history

Rebasing changes hashes. Anyone who already pulled your old-hashed commits will have a divergent history that requires force-push reconciliation. Rule: rebase local work, never shared work.

Aliases the pros type

Memorize the git rebase concept, then let one of these shortcuts make it instant. Aliases are real git config keys — add one with:

git config --global alias.st # → git rebase
AliasWhy people use it
g rb

Plain rebase shorthand.

g rbi

Interactive rewrite — the power button.

g rb main

Re-sync your feature onto updated main.

Command anatomy

git rebase <branch>
-i

Interactive mode — reorder, squash, fixup, drop commits.

--onto <base>

Replay commits onto an arbitrary new base.

--root

Also rebase the very first commit (requires interaction).

--abort

Cancel the process and restore the original branch.

When to reach for it

Keeping a feature branch in sync with a fast-moving main before merging.

Squashing a pile of WIP commits into one clean commit with -i.

You want a perfectly linear history (GitHub squash-merge culture).

Pro tip

Squash or fixup is the killer feature of interactive rebase for messy work: `git rebase -i main` then change 'pick' to 'fixup' on the commits you want folded. Your heavy WIP history becomes one elegant commit — but only before pushing.

Go deeper with

git merge

Fold the history of another branch into yours.

git pull

Fetch the remote and fold it into your current branch.

git reset

Move the branch pointer and undo your staging decisions.

git cherry-pick

Re-apply one specific commit onto your current branch.