Git Amend and Rebase: How to Safely Edit Past Commits

We’ve all been there: you’re two days deep into a feature, and your commit log is a mess of "wip," "fix typo," and "oops." When you finally open a pull request, that history looks less like a professional roadmap and more like a fever dream. Cleaning this up is a critical part of maintaining a readable project, but it’s easy to break things if you don’t understand the mechanics of git history modification.

The golden rule is simple: never rewrite history that has already been pushed to a shared branch. If you follow that, you’re safe. If you don’t, you’ll be the person responsible for everyone else’s merge conflicts on Monday morning.

Using Git Amend for the Last Commit

If you just realized you forgot to include a file or made a typo in the commit message of your most recent commit, you don't need a full rebase. You can use git amend.

It’s straightforward. Make your changes in the working directory, stage them, and then run:

Bash
git commit --amend --no-edit

The --no-edit flag keeps your existing message. If you want to change the message, just drop that flag, and your default editor will pop up.

One warning: git amend actually creates an entirely new commit object with a different hash. Your old commit is gone from the current branch. This is fine for local work, but if you’ve already pushed that commit to a remote server, you'll need to force-push (git push --force-with-lease) to overwrite it. Do this only if you are certain no one else has pulled your work yet.

Mastering Git Interactive Rebase

When you need to clean up multiple commits, a git interactive rebase is your best friend. It lets you reorder, squash, or rename commits from the last few entries in your log.

To start, decide how far back you want to go. If you need to clean up the last five commits, run:

Bash
git rebase -i HEAD~5

Git will open your configured text editor (like Vim or VS Code) with a list of those commits. You’ll see a list starting with pick. You can change these keywords to tell Git what to do:

I usually use reword to fix sloppy messages and squash to combine "wip" commits into a single, meaningful unit of work. After you save and close the file, Git will replay your commits one by one. If you hit a conflict, Git will pause, let you fix it, and then you just run git rebase --continue.

Git Best Practices for History Surgery

I’ve learned the hard way that history surgery should be surgical. Here is how I keep my workflow sane:

1. Keep it local: Never rebase branches that you share with teammates. If you’re collaborating on a feature branch, Git Rebase vs. Merge: A Guide to Clean Commit History is a great read to understand when to use which.
2. Use git rebase --continue patiently: When a rebase fails, don't panic. Git tells you exactly where you are. Read the prompt.
3. Use git reflog as a safety net: If you accidentally squash away something important, git reflog is your "undo" button. It tracks every movement of your HEAD pointer, allowing you to reset to exactly where you were before you started the rebase.
4. Squash before merging: If your team prefers a clean, linear history, use Git Squash and Merge: Streamlining Your Pull Request History to collapse your work into one atomic commit when you finally merge into main.

If you're still struggling with complex branch movements, I often rely on Mastering Git Rebase --onto: Moving Feature Branches Safely to keep my local branches organized without affecting the rest of the team's work.

Frequently Asked Questions

Can I edit a commit message from three days ago? Yes, but you’ll need an interactive rebase (git rebase -i). You’ll have to rebase back to the commit before the one you want to change, mark that commit as reword, and complete the rebase process.

What happens if I force-push to a shared branch? You will break the history for everyone else. They will have to perform complex manual merges or reset their local branches to match the new remote history. It’s a "nuclear" option that should be avoided at all costs.

Why does my commit hash change after amending? Git commits are cryptographic snapshots. Any change to the content, author, or message results in a new, unique hash. This is by design to ensure the integrity of the history.

I’m still careful every time I run a rebase. Even after years of using Git, I double-check the git log before I start. If you’re nervous, create a temporary backup branch (git branch backup-before-rebase) before you begin your cleanup. If you mess up, you can just delete your current branch and switch back to the backup.