Interactive Rebase: Squash, Reword, Edit and Reorder Commits Like a Pro

You've been there: a branch with 47 commits, half of them 'fix typo', 'oops', 'WIP', and 'please work'. Merging that into main is a crime scene. Interactive rebase is your cleanup crew — it rewrites history so your commits tell a coherent story. But it's not a toy. I've seen devs nuke weeks of work because they rebased a shared branch. This article is about using it right: squashing, rewording, editing, and reordering commits in production workflows. By the end, you'll know exactly when to reach for interactive rebase, how to execute each operation safely, and — more importantly — when to walk away.

Why Interactive Rebase Exists: The Messy History Problem

Every developer makes mistakes. You commit a typo, then fix it. You add a feature in three half-baked steps. Before you know it, your branch looks like a Jackson Pollock painting. Merging that into main pollutes the project history with noise. Interactive rebase lets you clean up before anyone sees it. It's the difference between a public diary and a curated memoir. Without it, code review becomes a nightmare — reviewers have to wade through 'fix' commits to find the actual logic. With it, each commit tells a single, coherent story.

# io.thecodeforge — DevOps tutorial

# Simulate a messy branch
git init messy-repo
cd messy-repo
echo "first draft" > file.txt
git add . && git commit -m "Add feature X"
echo "fix typo" >> file.txt
git add . && git commit -m "fix typo"
echo "actually working" > file.txt
git add . && git commit -m "WIP"
echo "final version" > file.txt
git add . && git commit -m "final"

# Now clean it up with interactive rebase
git rebase -i HEAD~4
# In editor: squash the last 3 commits into the first, reword the first commit
# Result: one clean commit "Add feature X"

Squashing Commits: The Art of the Single Logical Change

Squashing combines multiple commits into one. Use it when you have a series of 'fix' commits that should be part of the original commit. The classic pattern: you write a feature, then fix a bug in it, then improve formatting. Those three commits should be one. Squash merges their changes and lets you write a single message. The key: squash only commits that are conceptually the same change. Don't squash unrelated features — that defeats the purpose of atomic commits.

# io.thecodeforge — DevOps tutorial

# Start with a branch that has 3 commits for one feature
git log --oneline
# Output:
# a1b2c3d Add payment validation
# e4f5g6h Fix null pointer in validation
# i7j8k9l Add unit tests for validation

# Squash the last two into the first
git rebase -i HEAD~3
# In editor, change to:
# pick a1b2c3d Add payment validation
# squash e4f5g6h Fix null pointer in validation
# squash i7j8k9l Add unit tests for validation
# Save and exit, then write a new commit message: "Add payment validation with tests"

# Result: one commit
git log --oneline
# Output:
# m1n2o3p Add payment validation with tests

Rewording Commits: Fixing Messages Without Changing Code

Commit messages are documentation. A bad message like 'fix stuff' is useless. Rewording lets you change the message of any commit without altering its content. Use it when you realize a message is misleading, or when you want to follow a convention (e.g., 'feat: add login' instead of 'added login'). The operation is safe — it only changes the commit metadata, not the diff.

# io.thecodeforge — DevOps tutorial

# Change the message of the last 2 commits
git rebase -i HEAD~2
# In editor, change 'pick' to 'reword' on the commits you want to edit
# Save and exit, then Git opens an editor for each reworded commit
# Write the new message and save

# Example: change "fix bug" to "fix: correct off-by-one error in pagination"

Editing Commits: Splitting or Amending Mid-History

Editing a commit pauses the rebase at that commit, letting you amend its content. Use it when you need to split a commit into smaller ones, or when you realize a commit includes changes that belong elsewhere. The workflow: mark the commit with 'edit', then when Git stops, make your changes, stage them, and run git commit --amend to modify the commit. Then git rebase --continue to proceed. This is powerful but dangerous — you're rewriting history, and conflicts can cascade.

# io.thecodeforge — DevOps tutorial

# Suppose commit a1b2c3d added both login and logout. You want to split them.
git rebase -i HEAD~3
# Mark a1b2c3d as 'edit', save and exit
# Git stops at that commit

# Now reset to the previous commit, keeping changes staged
git reset HEAD^
# Now you have unstaged changes for both login and logout

# Stage and commit login only
git add login.html login.js
git commit -m "Add login page"

# Stage and commit logout only
git add logout.html logout.js
git commit -m "Add logout page"

# Continue rebase
git rebase --continue

Reordering Commits: Telling a Better Story

Sometimes commits are in the wrong order. Maybe you fixed a bug before adding the feature that introduced it. Reordering lets you rearrange commits to make logical sense. The rule: reorder only if the commits are independent — if commit B depends on changes in commit A, moving B before A will cause conflicts. Git will try to apply patches in the new order, and if they conflict, you'll have to resolve manually.

# io.thecodeforge — DevOps tutorial

# Current order:
# 1: Add user model
# 2: Add admin panel
# 3: Add user authentication

# You want authentication before admin panel
git rebase -i HEAD~3
# In editor, reorder lines:
# pick <hash> Add user model
# pick <hash> Add user authentication
# pick <hash> Add admin panel
# Save and exit

# Git will apply commits in the new order. If conflicts occur, resolve them and run:
git add .
git rebase --continue

When Not to Use Interactive Rebase

Interactive rebase is not for every situation. Never use it on commits that have been pushed to a shared branch — you'll rewrite history and break everyone's work. Also avoid it on commits that are tagged or referenced in release notes. If you need to remove sensitive data, use git filter-branch or git filter-repo instead. For simple message changes on the last commit, git commit --amend is faster. And if you're on a deadline, don't clean up history — just merge and move on. Perfection is the enemy of shipping.