If you have ever attempted to track down a regression bug using git bisect, only to find yourself navigating through hundreds of overlapping merge commits titled "fixed typo" or "WIP," you understand the profound pain of a poorly managed version control history. The default behavior for most junior engineers working in collaborative environments is to use git pull and git merge exclusively. While merging is entirely safe and mathematically sound, it creates a visual and historical nightmare. Every time a feature branch is merged, Git creates an explicit "merge commit" that ties the two timelines together. Over time, your repository's history begins to look like a tangled web of train tracks, making it nearly impossible to revert features cleanly or understand the chronological evolution of the codebase.
Professional engineering teams avoid this chaos by enforcing a strict "rebase-only" policy. Rebasing is the process of physically rewriting Git history to create a perfectly linear, chronological timeline of events. Instead of tying two branches together with a messy knot, rebasing unplugs your feature branch, moves it to the absolute tip of the main branch, and replays your commits one by one. This guide explains the mechanics of the interactive rebase workflow and demonstrates how to squash your disorganized work into atomic, production-ready commits.
The Mechanics of Rewriting History
To understand rebasing, you must understand how Git fundamentally stores data. Git does not store "diffs"; it stores snapshots of your filesystem at a specific point in time, heavily relying on cryptographic hashes (SHA-1) to identify each commit. When you execute git rebase main while checked out on a feature branch, Git identifies the exact common ancestor where your branch originally diverged from main.
Git then takes all the commits you made on your feature branch and temporarily saves them as raw patch files. Next, it aggressively moves the base pointer of your feature branch to point to the very latest commit on the main branch. Finally, it replays your saved patches, one by one, on top of this new base. Because the underlying base has changed, the cryptographic hash of every single one of your commits will change. You are literally creating brand new commits that contain the same code changes. This is why rebasing is incredibly powerful, but also why it must be used with caution: you should never, under any circumstances, rebase a branch that is publicly shared and being actively developed by other engineers.
The Interactive Rebase (Squashing Commits)
The true power of rebasing is unlocked when you introduce the --interactive (or -i) flag. Interactive rebasing allows you to pause the replay process and manually edit, delete, reorder, or combine (squash) your commits before they are permanently written to history. This is the secret to a perfectly clean main branch.
Imagine you are working on a feature and you have made six localized commits over three days: "start feature," "fix bug," "linting fixes," "more fixes," and "ready for PR." If you merge this directly, all of that useless noise pollutes the global repository history. Instead, you can squash them into a single, atomic commit using interactive rebase.
# Initiate an interactive rebase against the main branch
git rebase -i main
Executing this command will open your default terminal text editor (usually Vim or Nano) displaying a list of your commits in chronological order from top to bottom. Next to each commit is the command pick. To squash commits together, you simply change the word pick to squash (or just s) for all the commits you want to absorb into the commit directly above them.
# Inside the interactive rebase editor:
pick a1b2c3d start feature
squash e4f5g6h fix bug
squash i7j8k9l linting fixes
squash m1n2o3p more fixes
When you save and close the editor, Git will pause again, prompting you to write a brand new, unified commit message for this newly squashed super-commit. You can delete all the temporary WIP messages and write a single, professional description. Your messy feature branch has now been compressed into one perfectly clean commit, resting cleanly on top of the main branch.
Handling Rebase Conflicts Like a Professional
The primary reason developers avoid rebasing is the fear of merge conflicts. When Git attempts to replay your commits on top of the new base, it may discover that someone else modified the exact same lines of code. The rebase will immediately halt and warn you of a conflict.
Unlike a standard merge conflict where you are dealing with everything all at once, a rebase conflict happens one commit at a time. To resolve it, simply open your code editor, fix the highlighted conflict markers, and save the file. Then, you stage the resolution and tell Git to continue the process.
# 1. Fix the conflict in your code editor
# 2. Stage the resolved files
git add .
# 3. Tell the rebase to proceed to the next commit
git rebase --continue
If you ever get hopelessly lost or make a terrible mistake during a rebase, you have a built-in emergency escape hatch. You can execute git rebase --abort at any time. This instantly cancels the operation and returns your branch to the exact state it was in before you started, completely unharmed.
By adopting the interactive rebase workflow, you transform your Git history from a chaotic timeline of trial and error into a highly curated, professional ledger of atomic features. This discipline is the hallmark of a senior engineering team, enabling rapid rollbacks, easy code reviews, and absolute clarity when debugging legacy systems.
Sources
- Atlassian Git Rebase Tutorial: https://www.atlassian.com/git/tutorials/rewriting-history/git-rebase
- Official Git Documentation - Interactive Rebasing: https://git-scm.com/book/en/v2/
Disclaimer: "All content is for educational use only."