In partnership with

Git rebase is a powerful mechanism that allows you to rewrite Git commit history.

It does two things incredibly well.

  1. Keeping your git branches up to date

  2. Maintaining a clean git history

Let’s see how it works.

The Problem

You have been working on a project for a few days.

You made some commits. Finally, you’re ready to push.

But when you hit the command, an error occurs.

What happened?

A teammate updated the remote main branch while you were working.

Your commits are based on an old version, so Git won't accept them.

To make it work, you have to update your local branch.

And there are two ways.

option 1: merge

Run git pull.

This pulls changes from the remote and merges them with your code.

If you and your teammate touched the same file, you'll see conflicts.

Open the conflicting files, keep what you want, then stage and commit.

Now you can push.

This is the standard way to do stuff

But this also creates an extra commit every time you merge.

Do that often, and you will have a commit history that resembles Japan's Metro Map.

That’s why there’s another school of thought: rebase.

option 2: rebase

Every branch has a base commit.

Rebase moves it.

Instead of creating a merge commit, you move the base of your local branch to the latest version of the main:

What happens is that Git first archives the commits. Rebase the branch. And replay the commits one by one.

After resolving the conflicts, you can then push (using the force flag, since history has been rewritten).

What’s the point of this?

This doesn’t create an additional merge commit, which seems insignificant.

But when you work on more branches, rebase creates a much more readable history.

When to use (or avoid) rebase

Rebase is useful when working on a private/ local branch.

Like the branches you create off the main branch to work on a specific feature or bug.

Rebase keeps them up to date while keeping a clean commit history.

But it’s not a perfect solution.

Rebase rewrites history. And rewriting history that other people rely on will break their work.

So developers generally avoid rebasing a shared branch.

Find out why 100K+ engineers read The Code twice a week

Staying behind on tech trends can be a career killer.

But let’s face it, no one has hours to spare every week trying to stay updated.

That’s why over 100,000 engineers at companies like Google, Meta, and Apple read The Code twice a week.

Here’s why it works:

  • No fluff, just signal – Learn the most important tech news delivered in just two short emails.

  • Supercharge your skills – Get access to top research papers and resources that give you an edge in the industry.

  • See the future first – Discover what’s next before it hits the mainstream, so you can lead, not follow.

Fee from Anime Coders

PS: This article focuses on how rebase works rather than how to implement it. If you want to learn how to implement it, this article is a good starting point.

PPS: Have you tried integrating rebase into your workflow? How was the experience? Reply to let us know.

How did you like today's email?

Login or Subscribe to participate

Keep Reading