Interactive Rebasing
# 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: Standardgit 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.
8f4b2Add shopping cart UI
-
2.
3a9d1Fix button color
-
3.
7c2e9Fix 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.Your terminal will open a text editor (like Vim or Nano) showing this:
*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:
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
ito type,Escto stop typing,:wqto save and exit). If you hate Vim, rungit 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.
Explain the operational difference between the
rewordcommand and thesquashcommand during an interactive rebase.
- 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.
Initialize a new repository:
mkdir rebase-test && cd rebase-test && git init
-
2.
Create a base commit:
echo "V1" > file.txt && git add . && git commit -m "Base"
- 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"
`
-
4.
Run
git log --oneline. Observe your terrible commit history.
-
5.
Initiate the rebase:
git rebase -i HEAD~3
-
6.
In the editor, change the word
pick to squash (or s) next to the bottom two commits. Save and close the editor.
-
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.
-
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.