Of Incorrect History

Dealing With Messed Up Commit History

Most people encounter this problem when they've pushed commits to a shared branch and immediately realize one of them has a broken change, wrong file, or completely misplaced content. The panic sets in around 2 AM when the build breaks and you're the only one who touched the code. I've been there several times, mostly on projects where the team was still learning version control discipline. The first thing you need to understand is that git was built to handle this exact scenario. It tracks every change as a snapshot, and those snapshots can be rearranged before they ever reach anyone else. Once they're pushed to a shared location, things get messier, but not impossible.

The most common situation is Of Incorrect History where you've made a series of small commits while working on a feature and now realize they're scattered, out of order, or each one breaks the build independently. Nobody wants to read a PR with fifteen commits titled "fix," "fix again," and "wip." It makes code review painful and the git log useless for understanding what actually changed.

Fixing Commits Before They're Pushed

This is the easy case. Run git log --oneline -10 to see your recent commits and find where the problems start. Then use git rebase -i HEAD~N where N is the number of commits you want to look back at. The interactive rebase opens an editor with a list of your commits, each prefixed with the word "pick."

Change "pick" to "squash" or "fixup" for commits you want to merge into the one above it. "Squash" combines them and lets you edit the combined commit message. "Fixup" merges them and discards that commit's message entirely, using the parent's message instead. I usually squash anything that looks like a half-finished attempt at a change and fixup the trivial follow-up commits. You can also reorder lines to change the sequence, which matters if one commit introduced a bug that a later commit was supposed to fix. After you save and close the editor, git replays your commits in the new order. If two commits touch the same file, you might hit a merge conflict mid-rebase. Resolve it the normal way, then run git rebase --continue. This step trips people up because they don't realize conflicts during an interactive rebase are handled identically to regular merges.

When Commits Are Already Pushed

This is where things get complicated and where I've made mistakes that affected other people's work. If you rewrite history on a branch that others have already cloned and committed against, their clones become inconsistent with the shared branch. Git tracks history by commit hash, and changing those hashes means everyone downstream has to reset their local copies.

I learned this the hard way on a project with about eight contributors. I rewrote the main branch history on a Friday evening to clean up a messy series of commits. By Monday, three people had new commits on their local copies that couldn't fast-forward onto my rewritten history. We spent about two hours untangling it. The workaround was straightforward but not comfortable: I asked everyone to back up their work, delete their local branch, and fetch the rewritten version fresh. It worked, but the trust erosion was real. People don't like losing their commit history even when it's sloppy. The safer approach for pushed commits is to add corrective commits rather than rewriting. If a previous commit introduced a bug, make a new commit that fixes it. The git log will show both the mistake and the correction, which is honest and avoids disrupting anyone else's workspace. This is less elegant but rarely causes problems. Most teams prefer this on shared branches.

A Specific Edge Case That Almost Cost Me a Deadline

I once had a commit that accidentally included a configuration file with hardcoded credentials. I pushed it to a private repository on a Friday night, thinking it was fine because the repo wasn't public. By Saturday morning, I'd forgotten about it and went to sleep. Sunday, I remembered and realized the credentials were still in the history even after I deleted the file in a new commit. The old commit containing the leaked data was still there, accessible to anyone with read access to the repo.

The fix required git filter-branch --tree-filter 'rm -f config.py' HEAD~5 to rewrite the last five commits and remove the file from all of them. After that, I pushed with --force-with-lease, which is safer than a plain force push because it refuses to overwrite remote changes if someone else pushed something in the meantime. I also rotated the credentials immediately after, because removing them from history doesn't undo the fact that they existed in a commit anyone could have pulled down. This whole situation took about forty minutes and caused approximately three days of anxiety. Another thing people overlook is that git reflog exists for a reason. It records every position your HEAD has occupied, even after you've reset or rebased away from those commits. If you accidentally throw away commits you meant to keep, reflog is usually the recovery tool. Run git reflog to see a list of your recent HEAD positions with their commit hashes, then use git checkout -b recovery-branch <hash> to create a new branch at any of those points. This has saved me more times than I can count. The third thing is understanding the difference between --soft, --mixed, and --hard flags on git reset. --soft moves HEAD back but keeps all your changes staged. --mixed moves HEAD back and unstages your changes but leaves them in your working directory. --hard moves HEAD back and discards all changes. Most people default to --hard because it's the simplest to explain, but --mixed is almost always the right choice when you're trying to undo a commit without losing your work.

Practical Limits of History Rewriting

Not every problem is solvable by rewriting. If you've accidentally committed sensitive data into a repository that's been mirrored or forked by external parties, no amount of git filter-branch or git BFG repo cleaner will remove it from those external copies. The data is out there. The best you can do is rewrite your own repository, force-push to update the canonical history, and hope that mirrors respect the rewrite. This never feels like enough.

Similarly, if your team uses a linear workflow with no merge commits and everyone pushes frequently to the same branch, interactive rebasing becomes impractical. You'll either constantly conflict with each other's work or end up force-pushing and disrupting collaborators. In those environments, the corrective-commit approach is the only viable path. It's uglier but it doesn't require coordinating with five other people every time someone makes a mistake. There's also the matter of CI/CD pipelines. Some projects are configured to validate branch history or refuse non-fast-forward updates. If your repository is set up this way, rewriting history isn't an option regardless of how clean you want the log to look. Check your branch protection rules before attempting anything that requires a force push. A lot of teams don't realize their admin has locked down the branch until they try and get a rejected push notification.