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.

Practice

1. What is the main purpose of using git rebase -i (interactive rebase)?

easy

A. To reorder, edit, or combine recent commits before sharing

B. To create a new branch from the current commit

C. To permanently delete the entire commit history

D. To push commits directly to the remote repository

Solution

1. Step 1: Understand the purpose of interactive rebase

   Interactive rebase allows you to change the order, combine, edit, or remove recent commits.

2. Step 2: Compare with other git commands

   Creating branches, deleting history, or pushing commits are different git operations.

3. Final Answer:

   To reorder, edit, or combine recent commits before sharing -> Option A

4. Quick Check:

   Interactive rebase = reorder/edit commits [OK]

Hint: Interactive rebase = rewrite recent commits easily [OK]

Common Mistakes:

• Confusing rebase with branch creation
• Thinking it deletes all history
• Assuming it pushes commits automatically

2. Which of the following is the correct command to start an interactive rebase for the last 3 commits?

easy

A. git rebase -i HEAD^^3

B. git rebase -i HEAD~3

C. git rebase -i HEAD~

D. git rebase -i HEAD^3

Solution

1. Step 1: Recall the syntax for interactive rebase

   The correct syntax uses HEAD~N to specify the last N commits, so HEAD~3 means last 3 commits.

2. Step 2: Check the options

   HEAD^3 and HEAD^^3 are invalid for this purpose; HEAD~ alone is incomplete.

3. Final Answer:

   git rebase -i HEAD~3 -> Option B

4. Quick Check:

   HEAD~3 selects last 3 commits [OK]

Hint: Use HEAD~N to select last N commits for rebase [OK]

Common Mistakes:

• Using HEAD^3 instead of HEAD~3
• Omitting the number after ~
• Using double carets ^^ incorrectly

3. Given the following interactive rebase todo list:

pick a1b2c3 Commit A
pick d4e5f6 Commit B
pick 789abc Commit C

If you change it to:

pick d4e5f6 Commit B
squash 789abc Commit C
pick a1b2c3 Commit A

What will happen after completing the rebase?

medium

A. Only Commit C will be applied, others dropped

B. Commits A and B will be combined, Commit C will be last

C. The rebase will fail due to invalid order

D. Commits B and C will be combined, and Commit A will be last

Solution

1. Step 1: Understand 'pick' and 'squash' in rebase

   'pick' applies a commit as is; 'squash' combines the commit with the previous one.

2. Step 2: Analyze the new order

   Commit B is picked first, Commit C is squashed into B, Commit A is picked last.

3. Final Answer:

   Commits B and C will be combined, and Commit A will be last -> Option D

4. Quick Check:

   squash merges commits; order changed [OK]

Hint: Squash merges commit into previous one in order [OK]

Common Mistakes:

• Thinking squash drops commits
• Assuming order stays same after rebase
• Confusing squash with fixup

4. You run git rebase -i HEAD~2 and change the second commit's action from pick to edit. After saving, what should you do next to modify that commit?

medium

A. Make changes, then run git commit --amend and git rebase --continue

B. Run git push immediately to update remote

C. Abort the rebase with git rebase --abort

D. Run git reset --hard HEAD~1 to undo the commit

Solution

1. Step 1: Understand 'edit' in interactive rebase

   When a commit is marked 'edit', rebase pauses to let you change it.

2. Step 2: Modify commit and continue rebase

   You make changes, amend the commit with git commit --amend, then continue with git rebase --continue.

3. Final Answer:

   Make changes, then run git commit --amend and git rebase --continue -> Option A

4. Quick Check:

   Edit = amend commit + continue rebase [OK]

Hint: Edit commit: amend changes, then continue rebase [OK]

Common Mistakes:

• Pushing before finishing rebase
• Aborting instead of continuing
• Resetting commits incorrectly

5. You want to clean up your last 4 commits by combining the second and third commits into one, and also reorder commits so the last commit becomes the first. Which interactive rebase todo list correctly achieves this?

pick 111aaa Commit 1
pick 222bbb Commit 2
pick 333ccc Commit 3
pick 444ddd Commit 4

hard

A. pick 444ddd Commit 4
squash 222bbb Commit 2
pick 333ccc Commit 3
pick 111aaa Commit 1

B. pick 444ddd Commit 4
pick 111aaa Commit 1
squash 222bbb Commit 2
pick 333ccc Commit 3

C. pick 444ddd Commit 4
pick 111aaa Commit 1
pick 222bbb Commit 2
squash 333ccc Commit 3

D. pick 111aaa Commit 1
pick 333ccc Commit 3
squash 222bbb Commit 2
pick 444ddd Commit 4

Solution

1. Step 1: Reorder commits to put last commit first

   Commit 4 (444ddd) should be first in the list to reorder it first.

2. Step 2: Combine second and third commits

   To combine commits 2 and 3, use 'pick' on commit 2 and 'squash' on commit 3 immediately after.

3. Step 3: Verify the todo list

   pick 444ddd Commit 4
   pick 111aaa Commit 1
   pick 222bbb Commit 2
   squash 333ccc Commit 3

   places commit 4 first, then commit 1, then picks commit 2 and squashes commit 3, matching requirements.

4. Final Answer:

   pick 444ddd Commit 4
   pick 111aaa Commit 1
   pick 222bbb Commit 2
   squash 333ccc Commit 3

   -> Option C

5. Quick Check:

   Reorder + squash =

   pick 444ddd Commit 4
   pick 111aaa Commit 1
   pick 222bbb Commit 2
   squash 333ccc Commit 3

   [OK]

Hint: Put last commit first, squash 3rd into 2nd commit [OK]

Common Mistakes:

• Squashing commits in wrong order
• Not moving last commit to first position
• Using squash on wrong commits