Keep your commit history readable and avoid review shame

If your branch looks like a grocery list of tiny mistakes and experiments then you need to squash commits. This is the polite version of hiding your messy development process from future you and your teammates. Squash with git when you want a tidy commit history that actually explains what changed.

What squashing does and why it matters

Squashing folds multiple commits into one. That makes git log easier to scan and makes code reviews less painful. This is good for version control hygiene and your reputation.

Pick the commits to combine

First find the commits you want to merge together. Use a short log so you do not guess.

git log --oneline

Decide how many commits to rewrite. For the last three commits use HEAD~3 as your target range.

Start an interactive rebase and mark commits

Run an interactive rebase to tell git how to replay your work. This is where you pick which commits to fold.

git rebase -i HEAD~3

The editor will list commits with pick in front. Replace pick with squash to merge commit messages or with fixup to discard the subordinate message and keep the top message. Fixup is your lazy friend when you do not want to write a new message.

Quick example of actions

• pick keeps the commit as is
• squash merges the commit and prompts you to combine messages
• fixup merges but drops the commit message

Edit the combined commit message

After squashing git opens the editor to craft the final message. Keep the summary line concise and add an optional body for context. Explain the change so someone reading the history later will not curse you.

Push the rewritten history without causing drama

Once the rebase finishes the branch history has changed. To update the remote without stomping on a collaborator work use the safer force option instead of a blind force push.

git push --force-with-lease

This reduces the chance of overwriting someone else changes. If you know you are the only one working on the branch then a plain forced push still works but you are less of a hero for doing that.

Quick checklist to avoid disaster

• Run git log --oneline before and after the rewrite to confirm history looks sane
• Prefer fixup when your follow up commit already contains the original message so git can auto fold it
• Communicate with teammates if the branch is shared to avoid conflicts

Recap and final git tips

In short you pick a commit range run an interactive rebase mark commits as squash or fixup tidy the commit message and push with care. These git tips and git commands are standard practice for keeping a readable commit history and better reviews.

Now go fold those tiny commits into something presentable. Your future self will thank you or at least stop yelling at your terminal.