Interactive rebase is a powerful Git tool for cleaning up commit history before merging. 1) Use git rebase -i HEAD~n to rewrite the last n commits. 2) In the editor, replace 'pick' with commands like reword, squash, fixup, edit, or drop to modify commits. 3) Reorder lines to change commit sequence. 4) Save and follow Git’s prompts to complete the rebase. 5) Use git rebase --abort if errors occur. 6) After rebasing, push with git push --force-with-lease to safely update remote branches. Always rebase only local, unshared commits to avoid disrupting collaborators, ensuring a clean, logical, and maintainable project history.

Rewriting your Git history doesn’t have to be scary — when done right, interactive rebase is one of the most powerful tools for keeping your project history clean, logical, and easy to follow. Whether you're preparing a pull request or just tidying up local commits, git rebase -i gives you full control over how your changes appear.

Here’s how to master it without breaking anything.

What Interactive Rebase Actually Does

At its core, git rebase -i lets you rewrite, reorder, squash, edit, or remove commits in your branch before merging into main branches like main or develop. Unlike merge, which preserves every step exactly as it happened, rebase lets you present your work more cleanly.

It’s ideal for:

• Combining small, incremental commits ("WIP", "fix typo", "forgot a file") into meaningful units
• Reordering commits so they tell a clearer story
• Rewriting commit messages for clarity
• Removing unnecessary or sensitive changes

Important: Only rebase commits that haven’t been pushed to shared branches. Once others have based work on your commits, rewriting history can cause confusion and conflicts.

How to Start an Interactive Rebase

Use this command to begin:

git rebase -i HEAD~n

Replace n with the number of recent commits you want to modify.

For example, to clean up the last 4 commits:

git rebase -i HEAD~4

This opens your default text editor with a list of the 4 commits, looking something like:

pick abc1234 Add user login feature
pick def5678 Fix login button alignment
pick ghi9101 Refactor auth logic
pick jkl2345 Update docs

Each line represents a commit, starting with the oldest. You can now choose what to do with each.

Common Commands in the Rebase Editor

You don’t just delete or move lines — you replace the word pick with one of several commands:

• reword – Keep the changes but edit the commit message
• squash – Combine this commit with the previous one (and edit the message)
• fixup – Combine with the previous commit, discarding this commit’s message (great for merging "fix typo" commits)
• edit – Pause during rebase to amend the commit (e.g., add forgotten files)
• drop – Remove the commit entirely (or just delete the line)
• reorder – Move lines around to change commit order

For example, turning this:

pick abc1234 Add user login feature
pick def5678 Fix login button alignment
pick ghi9101 Refactor auth logic

Into this:

pick abc1234 Add user login feature
squash def5678 Fix login button alignment
reword ghi9101 Refactor auth logic

…will merge the second commit into the first (with a chance to rewrite the combined message), and let you change the third commit’s message.

Save and close the file, and Git walks through your instructions step by step.

Practical Tips for Safer, Smarter Rebasing

• Always pull the latest changes first
  Make sure your branch is up to date with the base branch (e.g., main) before rebasing locally.

• Preview your changes with git log
  Run git log --oneline before starting to count the right number of commits and understand their order.

• Use fixup liberally for cleanup commits
  If you have multiple “typo”, “l(fā)int”, or “forgot file” commits, mark them as fixup to keep the history focused.

• Break large changes into logical chunks with edit
  If a commit does too much, use edit to pause and split it:

  1. During the rebase, when paused, use git reset HEAD~1 to uncommit while keeping changes
  2. Stage and commit parts separately
  3. Run git rebase --continue when done

• Abort if things go wrong
  If you get lost, just run:

  git rebase --abort

  This returns everything to how it was before the rebase.

After the Rebase: Push Carefully

If you’ve already pushed your branch, you’ll need to force-push after rebasing:

git push --force-with-lease

This is safer than --force because it fails if someone else has pushed new commits to the same branch — preventing accidental overwrites.

Many teams use protected branches and require force-push permissions, so coordinate with your team before rewriting shared history.

Basically, interactive rebase is about presenting your work well, not changing what was done. Used wisely, it keeps your project history readable, professional, and maintainable.

Just remember: clean history is helpful, but not at the cost of collaboration. Rebase your own branches, not shared ones.

The above is the detailed content of Mastering Interactive Git Rebase for a Cleaner History. For more information, please follow other related articles on the PHP Chinese website!