Stop 05 · Git & GitHubTopics · 6/11

Rebase

Part of the Frontend Developer Roadmap

In short

Rebase is merge's tidy cousin. It replays your commits on top of the latest main, so history looks like one straight line instead of a tangle.

`git rebase` replays your branch's commits on top of another branch's latest history, producing a cleaner, linear history than a merge would. Rebase rewrites commit identities, so it is powerful for cleaning up local history but requires care whenever other people already depend on those commits.

The jaadu mascot holds an ID card and steps back into the end of a canteen queue.

Think of it like this

Rejoining the canteen queue

You stood in the queue, but ten people got served while you went to fetch your ID card. Rebase is stepping back in at the current end of the queue, with your same order, as if you'd joined just now.

Watch it happen

Updating your branch with rebase

Your branch
GitHub

git fetch origin

1/5You download the latest commits, including two new ones on origin/main. Your files don't change yet.

The big ideas

What you need to know

A straight history

Your commits are replayed after the newest main commit. No merge commit, just one clean line.

Commits get new IDs

Rebase rewrites your commits. Same changes, but brand new hashes.

Golden rule

Never rebase commits that others have already pulled. Rewriting shared history breaks their copies.

Clean up before a PR

git rebase -i lets you squash 'typo fix' commits into one tidy commit before others review.

See it in code

Walk through the code

bash
1git switch feature/search2git fetch origin3git rebase origin/main4 5# If a conflict stops the rebase:6#   fix the file, then7git add search.js8git rebase --continue9# or give up and go back:  git rebase --abort10 11# Your branch history changed, so a normal push is refused12git push --force-with-lease

1/4Go to your branch, download the latest from GitHub, and replay your commits on top of origin/main.

--force-with-lease refuses to overwrite if someone else pushed to the branch meanwhile. Plain --force would silently wipe their work.

Save yourself the pain

Common mistakes

Oops

Rebasing main or any branch your teammates are also working on.

Do this instead

Only rebase your own feature branch. For shared branches, use merge.

Oops

Using git push --force after a rebase.

Do this instead

Use --force-with-lease. It stops you if the remote has commits you haven't seen.

Your mission

Straighten a branch

~25 min

Quick check

Why shouldn't you rebase a branch that teammates have already pulled?

Go deeper

  1. 1Rebase a feature branch onto an updated `main` and compare the log to a merge. Validate your understanding by applying it in a small practical example.
  2. 2Learn the golden rule: never rebase commits that have already been pushed and shared. Focus on understanding the underlying reason it works, not only memorizing the definition.
  3. 3Practice an interactive rebase (`git rebase -i`) to squash a few commits together.

More topics at this stop

Stuck on this topic? Ask an Insider

Get 1:1 guidance from people who've walked this exact path — on the InsideEdge app.

Download
InsideEdge