Interactive rebase (git rebase -i) - Deep Dive

Overview - Interactive rebase (git rebase -i)

What is it?

Interactive rebase is a Git feature that lets you edit, reorder, combine, or remove commits in your branch history. It opens a text editor where you can choose how each commit should be handled. This helps you clean up your commit history before sharing your work. It is a powerful way to rewrite history safely on your local branch.

Why it matters

Without interactive rebase, your commit history can become messy with small fixes, typos, or out-of-order changes. This makes it hard for others to understand your work or find bugs. Interactive rebase lets you create a clear, logical history that tells a better story of your development process. It improves collaboration and code review quality.

Where it fits

Before learning interactive rebase, you should understand basic Git commands like commit, branch, and simple rebase. After mastering it, you can explore advanced Git workflows, conflict resolution during rebases, and tools like Git hooks or automated CI pipelines that rely on clean commit histories.

Mental Model

Core Idea

Interactive rebase lets you rewrite your branch’s commit history by choosing exactly how each commit should be changed, reordered, combined, or removed.

Think of it like...

It’s like editing a playlist of songs where you can reorder tracks, remove songs you don’t like, or merge short clips into one full song before sharing it with friends.

┌─────────────────────────────┐
│ Original Commits (oldest → newest) │
│  A → B → C → D → E         │
└─────────────┬───────────────┘
              │
              ▼
┌─────────────────────────────┐
│ Interactive Rebase Editor    │
│ pick A                      │
│ squash B                    │
│ edit C                      │
│ drop D                      │
│ pick E                      │
└─────────────┬───────────────┘
              │
              ▼
┌─────────────────────────────┐
│ New Commits (rewritten)     │
│  A → B+C (squashed) → C' → E│
└─────────────────────────────┘

Build-Up - 7 Steps

1

Foundation

Understanding Git commits and history

Concept: Learn what commits are and how Git stores them as snapshots in a timeline.

A commit in Git is like a snapshot of your project at a point in time. Each commit has a unique ID and points to its parent commit, forming a chain called history. This history shows how your project evolved step by step.

Result

You can see your project’s changes over time and move between different versions.

Understanding commits as snapshots helps you grasp why rewriting history changes the story of your project.

2

Foundation

Basic Git rebase concept

Concept: Rebase moves or reapplies commits from one base to another, changing their parent commit.

When you rebase, Git takes your commits and replays them on top of a different commit. This changes the base of your branch and can make history linear and cleaner.

Result

Your branch appears as if you started working from a newer point, avoiding messy merges.

Knowing that rebase rewrites commit parents prepares you to understand how interactive rebase modifies commits.

3

Intermediate

Starting an interactive rebase session

Concept: Use 'git rebase -i' to open an editor showing commits to modify.

Run 'git rebase -i HEAD~N' where N is the number of recent commits you want to edit. Git opens a text editor listing those commits with commands like 'pick' before each commit hash and message.

Result

You see a list of commits you can reorder, edit, squash, or drop.

Seeing commits as editable lines lets you control history precisely instead of blindly replaying commits.

4

Intermediate

Common interactive commands explained

🤔Before reading on: do you think 'squash' deletes a commit or combines it with the previous one? Commit to your answer.

Concept: Learn the main commands: pick, reword, edit, squash, fixup, drop.

- pick: keep the commit as is - reword: change the commit message - edit: pause to change the commit content - squash: combine this commit with the previous one and edit message - fixup: combine with previous commit, discard this commit’s message - drop: remove the commit entirely

Result

You can customize each commit’s fate during the rebase.

Knowing these commands lets you clean history by merging small fixes or removing mistakes.

5

Intermediate

Resolving conflicts during interactive rebase

🤔Before reading on: do you think conflicts during rebase stop the process permanently or can you fix and continue? Commit to your answer.

Concept: Conflicts can happen when commits change the same lines; you must fix them manually.

If Git reports conflicts, open the files, fix the conflicts, then run 'git add ' and 'git rebase --continue' to proceed. You can also abort with 'git rebase --abort'.

Result

You successfully resolve conflicts and complete the rebase.

Understanding conflict resolution during rebase prevents frustration and data loss.

6

Advanced

Editing commits during rebase

🤔Before reading on: do you think 'edit' lets you change only the message or also the files in a commit? Commit to your answer.

Concept: The 'edit' command pauses the rebase to let you change the commit’s content or message.

When Git stops at an 'edit' commit, you can modify files, stage changes, and then run 'git commit --amend' to update the commit. After that, run 'git rebase --continue' to proceed.

Result

You can fix mistakes or add changes inside past commits.

Knowing how to amend commits mid-rebase gives you powerful control over your history.

7

Expert

Rebase internals and commit rewriting

🤔Before reading on: do you think rebase changes original commits or creates new ones? Commit to your answer.

Concept: Rebase creates new commits with new IDs instead of modifying existing ones.

Git applies each commit as a patch on the new base, creating new commits with new hashes. The old commits remain in the repository until garbage collected. This is why rebasing rewrites history and can cause issues if shared.

Result

You understand why rebasing changes commit IDs and why force-push is needed after rebasing shared branches.

Knowing that rebase creates new commits explains why rewriting history requires caution and coordination.

Under the Hood

Interactive rebase works by extracting the selected commits as patches, then applying them one by one onto a new base commit. During this process, Git allows user intervention to modify the sequence or content of commits. Each applied commit is a new object with a new hash, preserving the original commits until garbage collection. The rebase process updates branch pointers to the new commit chain once complete.

Why designed this way?

Git was designed to keep commits immutable for integrity and traceability. Instead of changing commits in place, rebase creates new commits to preserve history safety. Interactive rebase adds user control to this process, allowing history rewriting without losing data. This design balances flexibility with safety and auditability.

┌─────────────┐
│ Old Base    │
└─────┬───────┘
      │
      ▼
┌─────────────┐      ┌─────────────┐      ┌─────────────┐
│ Commit A    │      │ Commit B    │      │ Commit C    │
└─────┬───────┘      └─────┬───────┘      └─────┬───────┘
      │                   │                   │
      ▼                   ▼                   ▼
┌───────────────────────────────────────────────┐
│ Extract patches from commits A, B, C           │
└───────────────────────────────────────────────┘
      │
      ▼
┌─────────────┐      ┌─────────────┐      ┌─────────────┐
│ Apply patch │      │ Apply patch │      │ Apply patch │
│ for A       │      │ for B       │      │ for C       │
└─────┬───────┘      └─────┬───────┘      └─────┬───────┘
      │                   │                   │
      ▼                   ▼                   ▼
┌─────────────┐      ┌─────────────┐      ┌─────────────┐
│ New Commit  │      │ New Commit  │      │ New Commit  │
│ A'          │      │ B'          │      │ C'          │
└─────────────┘      └─────────────┘      └─────────────┘
      │                   │                   │
      └───────────────┬───┴───────────────────┘
                      ▼
               ┌─────────────┐
               │ Updated     │
               │ Branch Tip  │
               └─────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does interactive rebase change commits on the remote repository automatically? Commit yes or no.

Common Belief: Interactive rebase changes commits everywhere, including remote branches automatically.

Reality: Interactive rebase only changes your local commits. To update remote branches, you must force-push explicitly.

Why it matters: Assuming remote updates automatically can cause confusion and lost work if you forget to push or force-push after rebasing.

Quick: Can you safely rebase commits that others have already based work on? Commit yes or no.

Common Belief: You can rebase any commits anytime without affecting others.

Reality: Rebasing commits shared with others rewrites history and can cause conflicts or lost work for collaborators.

Why it matters: Misusing rebase on shared commits can break team workflows and require complex fixes.

Quick: Does 'squash' delete the commit or combine it with the previous one? Commit delete or combine.

Common Belief: Squash deletes the commit entirely.

Reality: Squash combines the commit with the previous one, merging their changes and messages.

Why it matters: Misunderstanding squash leads to accidental loss of changes or messy commit messages.

Quick: Does 'edit' during rebase only allow changing commit messages? Commit yes or no.

Common Belief: Edit only lets you change the commit message.

Reality: Edit lets you change both the commit content (files) and message.

Why it matters: Thinking edit is limited causes missed opportunities to fix code inside commits.

Expert Zone

1

Interactive rebase rewrites commits by creating new objects, so any references to old commits (like tags or other branches) remain unchanged and can cause confusion.

2

Using 'fixup' instead of 'squash' automatically discards the commit message, which is useful for cleaning up minor fix commits without cluttering history.

3

Rebasing merges with complex histories can cause subtle conflicts that require careful manual resolution to avoid losing changes.

When NOT to use

Avoid interactive rebase on public branches that others use; instead, use merge commits to preserve history. For large-scale history rewriting, consider tools like git filter-branch or git filter-repo. Use interactive rebase mainly for local, private branches before sharing.

Production Patterns

Developers use interactive rebase to clean feature branch commits before merging into main branches, ensuring a linear, readable history. Teams enforce rebasing policies in pull requests to avoid merge commits and simplify code review. Some CI pipelines reject non-rebased branches to maintain history quality.

Connections

Version Control Systems

Interactive rebase builds on the concept of version control by allowing history rewriting, unlike simpler commit models.

Understanding interactive rebase deepens your grasp of how version control systems manage changes and history.

Database Transactions

Both interactive rebase and database transactions involve applying a series of changes atomically with the ability to rollback or modify steps.

Knowing how transactions work helps understand the safety and rollback features during rebasing.

Editing a Video Timeline

Interactive rebase is like editing a video timeline where clips (commits) can be cut, reordered, merged, or removed to create a smooth final video.

This connection shows how complex sequences can be rearranged for clarity and flow, similar to code history.

Common Pitfalls

#1 Forgetting to force-push after rebasing a shared branch

Wrong approach:

git push origin feature-branch

Correct approach:

git push --force-with-lease origin feature-branch

Root cause:

Learners assume normal push updates remote after history rewrite, but Git rejects non-fast-forward updates without force.

#2 Rebasing commits that others have already pulled and based work on

Wrong approach:

git rebase -i origin/main (on a shared branch without coordination)

Correct approach:

Use git merge or coordinate with team before rebasing shared commits

Root cause:

Misunderstanding that rebasing rewrites history and breaks others’ work.

#3 Using 'drop' to remove a commit without checking its dependencies

Wrong approach:

drop commit-hash in rebase editor without verifying impact

Correct approach:

Review commit changes carefully before dropping to avoid losing important code

Root cause:

Assuming commits are independent when they may depend on each other.

Key Takeaways

Interactive rebase lets you rewrite your commit history by editing, reordering, combining, or removing commits before sharing your work.

It works by creating new commits on top of a new base, preserving original commits until garbage collected.

Using interactive rebase improves code history clarity, making collaboration and code review easier.

Rebasing shared commits requires caution and coordination to avoid breaking others’ work.

Mastering conflict resolution and commands like squash, fixup, and edit unlocks powerful history editing capabilities.