Skip to main content
Advanced Git Commands
CHAPTER 04 Advanced

Interactive Rebasing

Updated: May 15, 2026
20 min read

# CHAPTER 4

Interactive Rebasing

1. Introduction

A developer's local commit history is often a chaotic stream of consciousness: "Add feature," "Fix typo," "Whoops, fix typo again," "Forgot a semicolon." While this granular history is helpful during active coding, pushing this mess to a public repository is unprofessional. It pollutes the team's log, making it impossible to review code or track meaningful changes. Enter Interactive Rebasing (git rebase -i), the most powerful history-rewriting tool in Git. In this chapter, we will learn how to pause time, open an interactive editor, and completely rewrite our past—squashing, rewording, and reordering commits to present a pristine, logical history to our team.

2. Learning Objectives

By the end of this chapter, you will be able to:
  • Execute an interactive rebase (git rebase -i).
  • Understand the interactive rebase instruction sheet.
  • "Squash" multiple messy commits into a single cohesive commit.
  • "Reword" poorly written commit messages in the past.
  • Reorder or permanently drop (delete) specific commits from history.

3. Beginner-to-Advanced Explanations

The Beginner Rebase: Standard git rebase main blindly takes your commits and replays them on top of main automatically.

The Interactive Rebase: Interactive rebasing intercepts the replay process. When you type git rebase -i, Git pauses the operation, opens a text file listing your commits, and asks: *"Before I replay these, do you want me to change them?"* You act as an editor. You can tell Git to:

  • pick: Keep the commit exactly as it is.
  • reword: Keep the code, but let me change the commit message.
  • squash: Take the code from this commit and smash it into the commit *above* it, combining them into one.
  • drop: Completely delete this commit from existence.

4. Real-World Workflow Examples

You are building a shopping cart over three days. Your commit history looks like this:
  1. 1. 8f4b2 Add shopping cart UI
  1. 2. 3a9d1 Fix button color
  1. 3. 7c2e9 Fix padding error

If you open a Pull Request with these three commits, the reviewer will be annoyed. They don't care about your padding errors. They just want to review the final shopping cart. *The Solution:* You run git rebase -i HEAD~3. You tell Git to squash commits 2 and 3 into commit 1. The result is a single, beautiful commit: "Implement complete shopping cart UI." You push this single commit to GitHub.

5. Git Command Walkthroughs

Let's look at the exact interface of an interactive rebase.
bash
12
# Tell Git you want to interactively rebase the last 3 commits
git rebase -i HEAD~3

Your terminal will open a text editor (like Vim or Nano) showing this:

text
12345678
pick 8f4b2 Add shopping cart UI
pick 3a9d1 Fix button color
pick 7c2e9 Fix padding error

# Rebase commands:
# p, pick = use commit
# r, reword = use commit, but edit the commit message
# s, squash = use commit, but meld into previous commit

*Note: The commits are listed in chronological order (oldest at the top, newest at the bottom).*

You manually edit the text file to look like this:

text
123
pick 8f4b2 Add shopping cart UI
squash 3a9d1 Fix button color
squash 7c2e9 Fix padding error

You save and close the editor. Git will then open a *second* editor allowing you to write the new, combined commit message.

6. Best Practices

  • The Golden Rule Applies Here: Interactive rebasing aggressively rewrites history (it changes SHA-1 hashes). You must NEVER interactively rebase commits that have already been pushed to a shared public branch. Only squash and reword commits on your local feature branch *before* you push them to the server.

7. Common Mistakes

  • Vim Panic: Interactive rebasing heavily relies on terminal text editors. If your default editor is Vim, beginners often get trapped, unable to type or save the file. (Press i to type, Esc to stop typing, :wq to save and exit). If you hate Vim, run git config --global core.editor "code --wait" to make interactive rebase open in VS Code instead!

8. Troubleshooting Tips

  • The Abort Hatch: If you are halfway through an interactive rebase, and the text file looks wrong, or you accidentally deleted a line and don't know what to do, just delete all the text in the file, save, and close it. Or, open a new terminal and type git rebase --abort. Git will cancel the operation and put everything back to normal.

9. Exercises

  1. 1. Explain the operational difference between the reword command and the squash command during an interactive rebase.
  1. 2. Why are the commits in the interactive rebase instruction sheet listed from oldest at the top to newest at the bottom? (Hint: Think about how Git replays them).

10. Mini Project: Rewrite Messy Commit History

Let's clean up a chaotic history.

Step-by-Step Walkthrough:

  1. 1. Initialize a new repository: mkdir rebase-test && cd rebase-test && git init
  1. 2. Create a base commit: echo "V1" > file.txt && git add . && git commit -m "Base"
  1. 3. Create 3 messy commits:
``bash echo "Line 1" >> file.txt && git commit -am "WIP: add line 1" echo "Line 2" >> file.txt && git commit -am "Fix typo in line 1" echo "Line 3" >> file.txt && git commit -am "whoops forgot line 3" `
  1. 4. Run git log --oneline. Observe your terrible commit history.
  1. 5. Initiate the rebase: git rebase -i HEAD~3
  1. 6. In the editor, change the word pick to squash (or s) next to the bottom two commits. Save and close the editor.
  1. 7. A new editor window opens asking for the final commit message. Delete all the messy "WIP" text and type: Add complete three-line feature. Save and close.
  1. 8. Run git log --oneline. Your three messy commits have vanished, replaced by one perfectly clean, professional commit!

11. FAQs

Q: What is the difference between
squash and fixup? A: They both combine code identically. squash pauses the rebase to let you combine the commit messages. fixup simply throws away the commit message of the newer commit and automatically uses the older commit's message, skipping the second text editor prompt. fixup is vastly faster when you don't care about preserving the "typo" commit messages.

12. Summary

In Chapter 4, we transformed from passive recorders of history into active editors of time. We mastered
git rebase -i`, the surgical tool used by senior engineers to curate their work before public presentation. We learned how to decipher the interactive instruction sheet, successfully squashing granular, chaotic commits into logical, coherent milestones. By enforcing the Golden Rule of never rewriting public history, we ensured that our pristine feature branches integrate seamlessly into the enterprise codebase.

13. Next Chapter Recommendation

We know how to rewrite an entire timeline. But what if we don't want the whole timeline? What if we just want to steal a single, perfect commit from a different branch? Proceed to Chapter 5: Cherry-Picking and Selective Commits.

Finish this Chapter

Save your progress on your learning path and prepare for coding interview challenges.

Discussion

Join the discussion

Log in or create a free account to participate.

Sort: ·