Before touching the mechanics, let’s build a precise mental model of what rebasing is in general, and what makes the “interactive” version fundamentally different from an ordinary rebase.

What Rebasing Means in the First Place

To understand interactive rebase, you first need to understand plain rebasing. In Git, a rebase takes a sequence of commits and replays them, one at a time, on top of a different starting point than where they were originally created. Imagine you started a new feature branch three days ago, and since then, three other commits have landed on the main branch. Rebasing your feature branch means Git temporarily sets your commits aside, moves your branch’s starting point forward to include those three new commits, and then reapplies your own commits on top, one by one, as if you had started your work today instead of three days ago. The end result looks as though your work happened after the latest changes, producing a clean, straight-line history with no crossing branches.

What Makes It “Interactive”

An ordinary rebase runs automatically from start to finish with no input from you beyond resolving conflicts if they occur. An interactive rebase inserts a deliberate pause before that replay begins: Git opens a text editor showing every commit about to be replayed, one per line, and lets you decide — commit by commit — exactly what should happen to it. Should it be kept exactly as is? Reworded? Merged into the commit before it? Dropped entirely? Split apart? Interactive rebase turns the otherwise mechanical process of “replay these commits” into an editable checklist you control before a single commit is actually replayed.

The Fundamental Trade Rebasing Makes

Every rebase, interactive or not, makes the exact same trade: it produces a cleaner-looking history in exchange for creating entirely new commits. This is worth stating plainly, because it surprises many newcomers — a rebased commit is never truly “the same commit, moved.” Git commits are identified by a hash calculated from their content, including their parent commit. The instant a commit’s parent changes, as it does the moment it’s replayed onto a new base, its hash changes too, which means rebasing always produces brand-new commit objects, even when the actual code change inside them looks byte-for-byte identical to the original.

How Interactive Rebase Relates to Ordinary Commit Amending

Many developers first meet the idea of rewriting history through a much smaller, simpler command that lets you fold new changes into your single most recent commit — a convenient shortcut, but one that only ever reaches backward exactly one commit. Interactive rebase is best understood as the general, fully extended version of that same underlying idea: instead of being limited to only your very last commit, it opens up an entire chosen range of recent commits at once, letting you apply that same kind of correction, reordering, or removal to any of them, not just the most recent one. Developers who are already comfortable amending their latest commit typically find interactive rebase a natural, logical next step, rather than an entirely unfamiliar concept.

Choosing How Far Back to Rebase

Every interactive rebase requires you to specify a starting point — either a specific commit to rebase onto, or a count of how many recent commits to include, measured backward from your current position. Choosing this starting point correctly matters: pick too few commits, and the cleanup you want to perform on an earlier commit won’t even appear in your editable plan; pick too many, and you risk pulling in commits that were already shared with others, reopening exactly the sharing risks discussed later in this article. A useful habit is to first look at a graphical view of recent history to visually confirm exactly which commits are still private to you before deciding how far back the rebase should reach.

Interactive rebase is built from a small, well-defined set of moving parts: a todo list, a set of commands you can assign to each line, and a temporary working state Git maintains while the rebase is in progress.

The Todo List

The centerpiece of interactive rebase is a plain text file Git generates and opens in your configured text editor the moment the rebase begins. Every commit scheduled to be replayed appears as one line, listed in the order it was originally created, each prefixed with a command word — pick by default — followed by that commit’s short identifier and its message. This file is exactly as editable as any other plain text file: you can delete lines, reorder them, and change the command word at the start of each one. Once you save and close it, Git reads your edited instructions and begins carrying them out, one line at a time, from top to bottom.

The Command Vocabulary

Each line in the todo list can be assigned one of several commands, and understanding all of them is really understanding the full toolbox interactive rebase offers.

Temporary State During the Rebase

While an interactive rebase is in progress, Git maintains a set of temporary bookkeeping files describing exactly where it is in the process — which commit it’s currently working on, which commands remain, and what the original branch position was before the rebase began. This temporary state is what allows you to pause partway through (when using edit, or when a conflict occurs), make changes, and then tell Git to continue exactly where it left off, rather than needing to restart the whole sequence from scratch.

Now let’s open the hood and trace exactly what Git does internally, from the moment you start an interactive rebase to the moment it finishes.

Step One: Building the Plan

When you start an interactive rebase, Git first identifies exactly which commits sit between your chosen new base and your branch’s current tip — this range becomes the todo list’s contents. Git writes this list to a temporary file and opens it in your text editor, then waits. Nothing about your repository’s actual history changes yet at this point; you’re purely editing a plan, not touching real commits.

Step Two: Detaching and Replaying

Once you save your edited plan, Git moves your working position to the new base commit, entering what’s called a “detached HEAD” state — meaning your current position temporarily isn’t pointing at the tip of any named branch, only at a specific commit. From there, the replay engine works through your todo list top to bottom. For each picked commit, Git essentially computes the exact code change that commit originally introduced, then attempts to apply that same change on top of whatever the history currently looks like at this new position, before creating a fresh commit to record it.

flowchart TD
    A["Start: git rebase -i"] --> B["Git builds todo list\nfrom commit range"]
    B --> C["Editor opens\nfor you to edit plan"]
    C --> D["You save and close"]
    D --> E["HEAD detaches to\nnew base commit"]
    E --> F["Replay engine processes\neach line top to bottom"]
    F -->|pick/squash/fixup| G["New commit created\nwith new hash"]
    F -->|reword/edit| H["Rebase pauses for\nyour input"]
    F -->|conflict| I["Rebase pauses for\nconflict resolution"]
    G --> F
    H --> F
    I --> F
    F -->|todo list complete| J["Branch pointer moves\nto final new commit"]
    

Step Three: Handling Each Command Internally

A reword command causes the replay engine to apply the change exactly as normal, but instead of automatically reusing the original commit message, it pauses and opens your editor so you can supply a new one before the commit is finalized. An edit command applies the change and then stops completely, leaving you in that detached state with the commit already made, free to modify files, stage additional changes, or amend the commit however you like, before manually telling Git to resume the rebase. A squash or fixup command doesn’t create a separate commit at all — instead, it combines the change with the commit immediately above it in the plan, producing one single new commit representing both changes together, with squash prompting you to merge or edit both original messages and fixup silently discarding the folded-in commit’s message. A drop command simply skips a commit’s change entirely, as though it never existed in the replayed history.

Step Four: Finishing the Rebase

Once every line in the todo list has been processed, Git moves your original branch name to point at the final new commit produced by the replay — completing the transition from detached HEAD back to a proper, named branch position. At this point, the rebase is finished: your branch now points to an entirely new chain of commits, structurally similar to the original sequence in content, but different in nearly every hash along the way.

Why Conflicts Can Appear Mid-Rebase

Because each commit is replayed as an independent change against whatever the code currently looks like at that point in the sequence, a change that applied perfectly well in the original history can sometimes fail to apply cleanly against a different base or a different surrounding sequence of commits. When this happens, the replay engine pauses exactly like it does for edit, leaving conflict markers in the affected files for you to resolve by hand before telling Git to continue with the remaining commits in the plan.

Understanding the Detached HEAD State

The “detached HEAD” state mentioned earlier is one of the most misunderstood moments in all of Git, largely because the terminology sounds more alarming than the reality actually is. Normally, your current position is described relative to a named branch — you’re “on” a branch, and that branch’s name automatically follows you forward as you commit. During an interactive rebase, however, you’re working with commits that don’t yet belong to any branch at all; they’re being constructed one at a time in a kind of temporary staging area. Only once the entire todo list finishes processing does Git take that finished sequence and attach your original branch name back onto it. This is precisely why interrupting a rebase partway through — closing your terminal, restarting your machine — doesn’t lose your original branch position; the branch name itself never actually moved until the very last step, and the reflog, covered in detail later, preserves exactly where things stood in the meantime.

Let’s trace a realistic, complete interactive rebase from start to finish, the way it actually unfolds during a normal development session.

How the Rebased Branch Reaches Everyone Else

None of this history rewriting affects anyone else until the rebased branch is shared — typically by pushing it to a remote repository like GitHub. Because every commit in the rewritten sequence has a new hash, a normal push will be rejected: the remote still holds the old sequence, and Git can tell the histories no longer share a simple, linear relationship. Sharing rebased history requires an explicit, deliberate override — usually a force push — which is exactly why interactive rebase carries real coordination risk once other people are involved, a topic explored fully in the Security chapter.

Interactive Rebase Inside a GitHub Pull Request Workflow

In a typical GitHub-based workflow, interactive rebase most commonly happens before a pull request is opened, or in response to review feedback while it’s still open — a developer cleans up their local commits, then pushes the rewritten history to update the same pull request branch. It’s worth distinguishing this clearly from GitHub’s own “rebase and merge” button, which performs a different, non-interactive rebase automatically at merge time to keep the target branch’s history linear; that button gives you no todo list and no opportunity to reword, squash, or drop commits — it simply replays the pull request’s existing commits as-is onto the latest target branch.

Interactive rebase is a genuinely powerful tool, but every bit of that power comes paired with a corresponding responsibility and risk.

The Core Trade-off: A Polished Story Versus an Honest Record

At its heart, interactive rebase forces a philosophical choice every team eventually has to make explicitly or implicitly: should commit history read like a polished, edited final draft, or like an honest, unedited record of exactly how the work actually happened, mistakes and all? There’s no universally correct answer — a clean, rebased history is easier to read and review months later, while an unedited history preserves a more complete, sometimes more informative record of the real development process, including false starts that occasionally turn out to matter.

Weighing the Trade-off in Practice

In practice, most experienced teams don’t treat this as an all-or-nothing philosophical stance but as a question of scope. The messy, exploratory reality of how a feature was actually built rarely needs to be preserved forever — what matters long-term is usually the finished, reasoned-about result, not every wrong turn taken along the way. At the same time, throwing away that context too aggressively, or too early, can occasionally erase genuinely useful information, such as an earlier attempt that reveals why a particular approach was ultimately rejected. The most common resolution is to apply interactive rebase liberally to private, in-progress work, where the messy reality has little lasting value, while being far more conservative about rewriting anything that has already been reviewed, discussed, or built upon by someone else, where the honest record starts to carry real, lasting value of its own.

Because interactive rebase rewrites history, it introduces risks that don’t exist during ordinary, forward-only development — both to project integrity and, in specific cases, to genuine security.

The Core Danger: Force-Pushing Over Shared History

The single most dangerous action connected to interactive rebase isn’t the rebase itself — it’s force-pushing the rewritten history to a branch other people are actively working from. Because the rewritten commits have entirely new hashes, an ordinary push is rejected outright; overriding that rejection with a force push tells the remote to simply accept your version as correct, discarding whatever it previously held at that branch name. If a teammate had already pushed additional commits on top of the old history in the meantime, a careless force push can make those commits effectively unreachable from the branch name anyone uses to find them.

Safer Force-Pushing

Git provides a safer variant of force-pushing specifically designed to reduce this risk — one that first checks whether the remote branch still matches what you last saw locally before overwriting it, and refuses the push if someone else has added commits you don’t yet have. This doesn’t eliminate the underlying risk of rewriting shared history, but it does prevent the single most common accident: silently overwriting a teammate’s work you simply hadn’t fetched yet.

Many hosting platforms, GitHub included, add another layer of protection on top of this at the repository level: administrators can configure specific branches, such as the main branch, to reject force pushes entirely, regardless of who is attempting them or which safety flags they use locally. This kind of server-side enforcement is generally considered the most reliable safeguard of all, since it doesn’t depend on every individual developer remembering to use the safer command-line option correctly every single time — it simply makes the dangerous action impossible against the branches an organization has decided are too important to risk rewriting.

Rewriting History to Remove Sensitive Data

Interactive rebase, and history rewriting more broadly, is sometimes used deliberately as a security response — specifically, to remove a secret or credential that was accidentally committed before anyone noticed. Using edit on the offending commit lets you amend it to remove the sensitive file or value, after which every commit that follows is automatically replayed on top of the corrected version, producing a history that no longer contains the secret anywhere in its normal chain. It’s essential to remember, however, that this alone is not a complete remedy: the old, unrewritten commits may still exist in reflogs, existing clones, forks, or cached views on a hosting platform, so any exposed credential should still be treated as compromised and rotated immediately, exactly as covered for other forms of accidental exposure in Git.

Because rebasing rewrites history, Git provides its own internal “logging” mechanism specifically for observing, tracking, and recovering from exactly this kind of operation.

The Reflog: Git’s Built-In Safety Net

Every time your local branch position changes for almost any reason — a commit, a checkout, and critically, a rebase — Git silently records that movement in a local log called the reference log, or reflog. This log isn’t shared with anyone else and isn’t part of your project’s real commit history; it’s a private, chronological record, kept only on your own machine, of everywhere your branches have pointed recently. Because interactive rebase moves your branch through a whole sequence of intermediate positions as it replays each commit, the reflog effectively becomes a step-by-step audit trail of the entire rebase, in order, including the exact position you started from before anything changed.

Recovering “Lost” Commits After a Rebase

This is precisely why commits that seem to disappear after a rebase — dropped by mistake, or lost through an error — are very rarely gone for good. Because the reflog remembers exactly where your branch pointed immediately before the rebase began, you can look up that earlier position and point your branch back at it directly, instantly restoring the original, pre-rebase sequence of commits as though the rebase had never happened. Git also automatically keeps a special, easy-to-reach reference to your position right before certain operations, including a rebase, making this kind of recovery especially quick to perform without needing to search the full reflog by hand.

Tracking Progress During a Long Rebase

For a rebase spanning many commits, Git provides ongoing visibility into exactly where the process currently stands — which commit is being worked on, how many remain, and the full plan as originally saved — readable at any pause point, whether that pause was caused by an edit, a conflict, or simply checking in mid-process. Combined with the exec command described earlier, which can run an arbitrary command — most commonly a test suite — after each individual commit is replayed, a team can effectively build automated verification directly into the rebase itself, catching a commit that silently breaks something long before the rebase even finishes.

Why This Matters More at Scale

This kind of built-in observability becomes increasingly valuable as the size and complexity of a rebase grows. Cleaning up three or four commits rarely needs much tracking at all — the whole operation is over in moments, and any mistake is immediately obvious. Cleaning up thirty or forty commits accumulated over weeks of work on a long-running feature branch is a different matter entirely: a conflict discovered halfway through can be genuinely disorienting without a clear sense of exactly which commit triggered it and how many remain afterward. Teams working with unusually long-lived branches often treat the reflog and the exec-driven test-verification pattern described above not as optional conveniences but as a near-mandatory part of safely rebasing anything beyond a small, easily-reasoned-about handful of commits.

Reading the Resulting History as a Metric

After a rebase completes, the cleanliness of the resulting history is itself a useful, if informal, metric. A graphical view of recent commits — showing messages, authors, and the branching structure in a compact, readable form — is commonly used immediately after a significant rebase specifically to visually confirm the result looks exactly as intended: a straight line of well-scoped, clearly messaged commits, with no leftover experimental or duplicate entries.

sequenceDiagram
    participant B as Your Branch
    participant R as Reflog
    participant H as Repository History
    B->>R: Position recorded before rebase
    B->>H: Interactive rebase runs
    H-->>B: Branch now points to new commits
    Note over B,R: Something looks wrong
    B->>R: Look up pre-rebase position
    R-->>B: Return saved reference
    B->>H: Branch reset to that position
    H-->>B: Original history restored
    

Teams that use interactive rebase well tend to converge on a small set of recurring, well-tested patterns — and there are equally well-known ways it goes wrong.

Proven Patterns

Anti-patterns to Avoid

A distilled checklist for using interactive rebase confidently, without the anxiety it often causes newcomers.

Best Practices

• Only rebase what you own. Treat any branch other people are already building on as off-limits for interactive rebase unless it’s been explicitly coordinated.
• Make a safety branch before a risky rebase. Creating a quick backup pointer to your current position before a complex rebase costs seconds and removes nearly all anxiety about the outcome.
• Read the whole todo list before saving. Understand every planned command in context before committing to the plan, rather than editing line by line without seeing the full picture.
• Resolve conflicts calmly, one at a time. A paused rebase is not a failure state — it’s the normal, expected way Git asks for your judgment on genuinely ambiguous changes.
• Verify the result before sharing. Look at the rewritten history and, ideally, rerun tests, before force-pushing anything to a remote.
• Know how to abort. A rebase can always be cleanly canceled mid-process, instantly restoring your branch to exactly where it was before you started, no different from never having begun.

Common Mistakes

Seeing how real teams and projects actually apply interactive rebase makes its role in professional workflows concrete.

Interactive rebase gives you deliberate, line-by-line control over how a sequence of your own commits gets rewritten before it becomes a permanent part of shared history. Internally, it works by building an editable plan, detaching from your branch, and carefully replaying each commit according to your instructions — reworded, combined, split, reordered, or dropped as needed — before pointing your branch at the freshly built result. That power comes from a simple, honest trade: every rebased commit is a genuinely new object with a new identity, which is exactly why sharing rebased history safely requires real care, coordination, and — ideally — a healthy respect for the reflog as your local safety net whenever something doesn’t go as planned.