Git Rebase: Keep History Linear Without Merge Commits

If git merge feels noisy, that’s because it can be. Lots of noisy merge commits make history harder to scan, especially when you’re just trying to understand what actually changed. git rebase takes a different approach: instead of creating a merge commit, it replays your branch commits on top of the latest base commit so your history stays clean and linear.

All the content from our Boot.dev courses are available for free here on the blog. This one is the “Rebase” chapter of Learn Git. If you want to try the far more immersive version of the course, do check it out!

What Does Git Rebase Actually Do?

Rebase moves your branch to a new base, then reapplies your commits on top of it.

Start here:

A - B - C    main
     \
      D - E    feature_branch

feature_branch was created from B, so it’s missing C from main. Rebasing takes D and E, and replays them on top of C.

A - B - C         main
         \
          D - E   feature_branch

Same logical changes, cleaner history. If you want the lower-level object model behind this, read Git Internals.

How Is Rebase Different From Merge?

git merge combines two branches and usually creates a merge commit. git rebase rewrites your branch commits so they look like they started from the newer base.

Merge is fine when you want a complete record of when branches came together… but frankly, I don’t usually want to commit all my weird local-dev-specific merge history to the main branch for all my coworkers to deal with. Rebase is great when you want a simple, straight line of commits in your git log.

How Do You Rebase a Feature Branch Onto main?

From your feature branch:

git switch update_dune
git rebase main

That does four things:

1. Finds the commit where your branch split from main.
2. Temporarily removes your branch commits.
3. Moves your branch to the latest commit on main.
4. Reapplies your commits one by one on top.

After rebasing, a log that used to fork now reads top-to-bottom in one line:

git log --oneline
# A
# B
# C
# D
# E
# H
# I

If you’re still getting comfortable with branches in general, read Git Branching first.

Why Do Commit Hashes Change After a Rebase?

Git commit hashes include parent references. When you rebase, the parent changes, so the hash has to change as well.

That means rebased commits are technically new commits, even if the code diff looks identical.

This is also why rebase can be scary when used incorrectly: you’re actually rewriting the git history, which can be disastrous if you’re forcing anyone else to do so as well. Only rebase your own temporary branches that no one else cares about.

When Should You Rebase Instead of Merge?

Use rebase on your own working branch when you want to:

• Pull in the latest changes from main without adding merge commits.
• Keep your pull request history easier to review.
• Keep git log --oneline --graph readable.

Use merge when preserving exact branch history matters more than keeping the graph clean.

When Should You Never Rebase?

Never rebase a public shared branch like main. If other people have based work on that history, rewriting it creates chaos and confusion.

[!warning] Rebase your private feature branches all day. Do not rebase shared public history.

Want to go deeper into conflict handling, interactive rebase, and fixing mistakes after history rewrites? Our Learn Git 2 course covers advanced workflows.