Rebasing Branches

Rebase is Git's tool for a clean, linear history — and one of the most misunderstood. By the end of this lesson you'll know how rebase differs from merge, how to replay your feature branch onto main, how to handle conflicts mid-rebase, and the one golden rule that keeps it safe.

Learn Rebasing Branches in our free Git course — a beginner-friendly interactive lesson with worked examples, a practice exercise and a quick reference.

Part of the free Git course at LearnCodingFast — hands-on lessons with examples you run in your browser, plus practice exercises and a quick quiz.

1️⃣ Rebase vs Merge

Both merge and rebase integrate one branch into another, but they leave different histories. Merge preserves both lines and may add a two-parent merge commit. Rebase replays your commits on top of the target's tip as new commits, producing a single linear line with no merge commit. Same end result in your files, very different-looking history.

2️⃣ Rebasing a Feature onto main

The everyday use of rebase: keep your feature branch current. Switch to the feature branch and run git rebase main . Git replays your commits on top of main's latest tip, rewriting them with new hashes . The result is a tidy, linear history — and a later merge into main can often fast-forward.

3️⃣ Handling Conflicts Mid-Rebase

Because rebase replays commits one at a time, a conflict can pause it partway. Fix the conflict markers in the file, stage it with git add , then run git rebase --continue — not git commit . If you'd rather give up entirely, git rebase --abort returns the branch to exactly where it started.

4️⃣ The Golden Rule

Never rebase commits you've already pushed and shared. Rebasing rewrites those commits into new ones with different hashes, so anyone who already pulled the originals ends up with a diverged history and painful conflicts. The safe pattern: rebase your own local, unpushed branches; use merge for anything public.

Your turn. Bring a feature branch up to date on top of main. Fill in the two blanks.

📋 Quick Reference

No commands given this time — just the plan. Diverge two branches, then rebase to make the history linear.

Practice quiz

What does git rebase do?

  • Deletes a branch
  • Merges two branches with a merge commit
  • Replays your commits on top of another branch's tip
  • Pushes to the remote

Answer: Replays your commits on top of another branch's tip. Rebase moves your branch's commits so they sit on top of the target branch.

How does rebase differ from merge in the history it produces?

  • Rebase produces a LINEAR history; merge can add a merge commit
  • Rebase adds a merge commit; merge stays linear
  • They produce identical history
  • Rebase deletes history

Answer: Rebase produces a LINEAR history; merge can add a merge commit. Rebase rewrites commits onto a new base for a straight line; merge may create a two-parent merge commit.

To replay your feature branch onto the latest main, you run...

  • git rebase feature (while on main)
  • git merge --rebase
  • git reset main
  • git rebase main (while on feature)

Answer: git rebase main (while on feature). From your feature branch, git rebase main replays feature's commits on top of main.

Do rebased commits keep their original hashes?

  • Yes, always
  • No — they're rewritten, so they get new hashes
  • Only the first one changes
  • Only on the remote

Answer: No — they're rewritten, so they get new hashes. Rebase creates new commits with new hashes because their base (parent) changed.

What is the GOLDEN RULE of rebasing?

  • Never rebase commits you've already pushed/shared
  • Always rebase main
  • Rebase before every commit
  • Rebase only on Fridays

Answer: Never rebase commits you've already pushed/shared. Rebasing rewrites history, which breaks collaborators who already have those commits.

Why does rebasing shared commits cause problems?

  • It's slow
  • It deletes files
  • Teammates' history diverges from your rewritten commits
  • It can't be pushed at all

Answer: Teammates' history diverges from your rewritten commits. Others still have the old commits; your new hashes no longer match, causing conflicts.

A good use of rebase is...

  • Rebasing the public main branch
  • Updating your LOCAL feature branch onto the latest main before merging
  • Rebasing a teammate's branch
  • Rebasing every release tag

Answer: Updating your LOCAL feature branch onto the latest main before merging. Rebasing your own unpushed feature branch onto main gives a clean, up-to-date history.

If a rebase hits a conflict, which command continues after you fix it?

  • git rebase --skip-all
  • git merge --continue
  • git commit --rebase
  • git rebase --continue

Answer: git rebase --continue. After resolving and staging the conflict, git rebase --continue proceeds.

How do you abandon a rebase and return to where you started?

  • git reset --hard
  • git rebase --abort
  • git rebase --undo
  • Ctrl+C only

Answer: git rebase --abort. git rebase --abort restores the branch to its pre-rebase state.

After a successful on feature, what often happens on main?

  • main is deleted
  • main rewinds
  • A later git merge of feature into main can fast-forward (linear)
  • Nothing can be merged

Answer: A later git merge of feature into main can fast-forward (linear). Because feature now sits directly on top of main, merging it can fast-forward cleanly.