To understand rebase, we first need to see the messy situation it was built to address.

The problem: history that reflects timing, not intent

When multiple people work on a shared project at the same time, their commits naturally interleave based on when each person happened to save their work — not based on what actually makes logical sense as a readable story. One developer’s three small commits fixing a typo might end up scattered awkwardly between another developer’s much larger feature work, purely because of when each commit happened to be made. Left alone, a project’s history can end up reflecting the chaos of real-time collaboration rather than a clean, understandable narrative of how the project actually evolved.

The solution: replaying commits onto a new base

Rebase addresses this by letting you take a sequence of commits and move them, as a whole, onto a different starting point — most often, the latest version of the branch you’re eventually planning to merge into. Rather than merging two diverging histories together as they are, rebase effectively asks: “what if these commits had been made starting from right here, instead of from wherever they originally started?” It then reconstructs that alternate reality, one commit at a time.

Rebase is almost always discussed alongside its closest relative, merging, since both exist to solve the same underlying goal in fundamentally different ways.

Merging takes two separate lines of history and combines them by creating a brand-new commit with two parents, one pointing back into each original line. Nothing about either original line of history is changed — the merge commit simply sits on top, tying them together. Rebasing, by contrast, doesn’t create a joining commit at all. Instead, it takes one line of commits and moves them entirely, rewriting them so they appear to have been built directly on top of the other line from the very beginning.

flowchart TD
    subgraph Merge
    A1["main"] --> A2["main"]
    A2 --> A3["merge commit"]
    B1["feature"] --> B2["feature"]
    B2 --> A3
    end
    subgraph Rebase
    C1["main"] --> C2["main"]
    C2 --> D1["feature (replayed)"]
    D1 --> D2["feature (replayed)"]
    end
        

Understanding rebase’s internal mechanics removes a lot of the mystery around why it behaves the way it does.

When you rebase a branch onto a new base, Git doesn’t simply relabel or move the existing commits — it genuinely creates brand-new commits, one for each original commit being rebased, applying the same changes on top of the new base instead of the old one. Because a commit’s unique identifier is calculated from its content, including its parent, a commit built on a different base is, by definition, a completely different commit, even if the actual code change it introduces is identical.

A closer look at the pieces involved helps explain why rebase behaves the way it does under the hood.

Conceptually, Git treats each commit being rebased as a “patch” — a description of what changed, independent of exactly where it originally sat in history. Replaying a commit means applying that patch’s changes on top of whatever the new base currently looks like, then wrapping the result up as a new commit, carrying over the original author information and message, but generating a fresh identifier and a fresh parent link pointing at the newly rebased position.

Tracing a rebase from start to finish shows exactly how your branch transforms at each stage.

sequenceDiagram
    participant You
    participant Branch as Your Branch
    participant Base as New Base
    participant History as Rebased History
    You->>Branch: Start rebase onto new base
    Branch->>Base: Identify divergence point
    Base-->>Branch: Confirm commits to replay
    loop For each original commit
        Branch->>History: Apply patch onto current tip
        History-->>Branch: New commit created
    end
    Branch->>You: Branch now points to final new commit
        

Before the rebase begins

Your branch and the target base have diverged — meaning both contain commits the other doesn’t have. Your branch’s own commits sit on top of an older point in the target’s history, rather than its current, latest state.

During the rebase

Git works through each of your branch’s unique commits in order, temporarily pausing the process if any commit’s changes can’t be applied automatically due to a conflicting change already present in the new base.

After the rebase completes

Your branch now consists entirely of new commits, each built directly on top of the new base, forming one continuous, linear sequence with no branching point visible at all — as though your work had been written starting from that exact point in history all along.

Beyond simply moving commits to a new base, rebase also offers a mode for actively reshaping the commits themselves.

Interactive rebase presents you with an editable list of the commits about to be replayed, and lets you decide, for each one individually, exactly what should happen to it. You might choose to keep a commit exactly as it is, combine it with the commit before it, reword its message, reorder it relative to other commits, or drop it from history entirely.

Like any powerful tool, rebase brings genuine benefits alongside real costs worth understanding clearly.

Because rebase fundamentally alters history rather than simply adding to it, it carries a distinct category of risk worth treating seriously.

Since rebased commits are brand-new objects with different identifiers, updating a shared branch after a rebase requires forcefully overwriting whatever was there before, rather than the normal, additive update. This is inherently a destructive operation from the perspective of anyone who already has a copy of the original commits — their local history will no longer match, and reconciling the two can range from a minor inconvenience to a genuinely confusing mess.

The specific danger of shared history

If someone else has already based their own new work on top of the original commits, and you then rebase and force-update the shared branch, their work now technically builds on commits that no longer exist in the shared history at all. This can lead to duplicated changes, confusing conflicts, and a significant cleanup effort to sort out whose history should actually be considered correct.

Used deliberately, rebase fits neatly into several well-established, healthy team workflows.

gitGraph
   commit id: "main: setup"
   commit id: "main: config update"
   branch feature
   checkout feature
   commit id: "feature: draft"
   commit id: "feature: cleanup"
   checkout main
   commit id: "main: hotfix"
   checkout feature
   commit id: "feature: rebased draft"
   commit id: "feature: rebased cleanup"
   checkout main
   merge feature id: "clean, linear merge"
        

Just as clearly as there are healthy patterns, there are well-known ways rebase gets misused, often with painful consequences.

A handful of consistent habits keep rebase a genuinely useful tool rather than a source of team-wide headaches.

Rebase plays a distinct, deliberate role in the workflows of many serious, high-quality software projects.

Large, disciplined open-source projects — including some of the most heavily contributed-to codebases in the world — commonly require contributors to rebase their work before it’s accepted, specifically to maintain a clean, linear project history that’s easier to review and reason about over the project’s entire lifetime. Individual engineers frequently use local, unshared rebasing purely as a personal tidying step, cleaning up their own exploratory commits into a clear, professional-looking sequence before ever opening a pull request.

Not immediately. The original commits typically remain in Git’s internal storage for a period of time, even though your branch no longer points to them, meaning recovery is often still possible shortly after a rebase if something goes wrong.

Because a commit’s identifier is calculated from its full contents, including its parent commit, replaying a commit onto a different parent inevitably produces a different identifier, even if the actual code change is identical.

It produces a cleaner-looking, linear history, but “cleaner” doesn’t automatically mean “better” — merging preserves exactly what happened, including genuine branching, which some teams value more than a simplified, linear story.

The rebase pauses at that specific commit, letting you resolve the conflict directly, after which the process continues replaying the remaining commits in sequence.

Yes. Rebase operations can typically be aborted partway through, restoring your branch to exactly the state it was in before the rebase began.

It’s generally discouraged, since it forces everyone else to reconcile their local history with the rewritten version. When genuinely necessary, it should be done deliberately, with clear communication to everyone affected beforehand.

Yes. Beyond rewording messages, interactive rebase allows editing a commit’s actual changes, combining it with others, reordering it, or removing it entirely from the sequence.

Rebase gives you the power to reshape history itself — taking a sequence of commits and rebuilding them, one at a time, on top of a new starting point, producing a clean, linear story instead of a tangle of joined branches. That power comes with real responsibility: because rebased commits are entirely new objects, using rebase on anything already shared with others can create genuine confusion and conflict across a team. Used thoughtfully, on local, unshared work, rebase is one of the most valuable tools for producing a readable, professional project history. Used carelessly, on commits others already depend on, it becomes a source of exactly the kind of chaos it was meant to prevent.