DEV Community

The AI producer
The AI producer

Posted on

9 Git Mistakes That Broke My Codebase (And the Exact Command That Fixed Each One)

We've all been there. A git push --force that wiped a teammate's work. A merge gone wrong. A commit on the wrong branch at 11pm. After years of using Git daily, I've made every mistake on this list — and each one taught me the one command that undoes it.

Here are the 9 mistakes that caused the most pain, and the exact recovery command for each.


1. I committed to the wrong branch

You meant to commit on feature/login, but you were on main. The commit is already there.

The fix:

git branch feature/login   # create the branch at current commit
git reset --hard HEAD~1    # move main back one commit
git checkout feature/login
Enter fullscreen mode Exit fullscreen mode

The commit isn't lost — git branch captured it before you moved main back.


2. I used git push --force and wiped someone's work

--force overwrites the remote history. If a teammate pushed first, their work vanishes.

The fix (use --force-with-lease instead):

git push --force-with-lease origin feature/login
Enter fullscreen mode Exit fullscreen mode

--force-with-lease checks that the remote hasn't moved since your last fetch. If it has, the push is rejected. This single flag has saved me more times than I can count.


3. I ran git reset --hard and "lost" uncommitted work

You had hours of uncommitted changes, ran git reset --hard, and panic set in.

The fix:

git reflog
git checkout <commit-sha> -- path/to/file
Enter fullscreen mode Exit fullscreen mode

Git keeps unreachable objects for ~30 days. git reflog shows every HEAD movement — find the commit where your work existed and restore it. Your changes are almost never truly gone.


4. I merged the wrong branch and the history is a mess

You merged main into feature by accident, and now the merge commit is polluting your branch.

The fix:

git reset --hard ORIG_HEAD
Enter fullscreen mode Exit fullscreen mode

ORIG_HEAD points to where you were before the last dangerous operation (merge, reset, rebase). It's Git's built-in undo for the last "big" action.


5. I accidentally added secrets to a commit (and pushed)

You committed an API key and pushed to a public repo. Deleting it in a new commit isn't enough — it lives in history forever.

The fix:

git filter-repo --path .env --invert-paths
git push --force
# THEN rotate the key immediately — assume it's compromised
Enter fullscreen mode Exit fullscreen mode

Use git filter-repo (the modern replacement for filter-branch). But the real fix is prevention: rotate the secret immediately. Once it's on a public remote, consider it leaked.


6. I did a messy merge commit when I wanted a clean history

Your pull request has 47 merge commits and looks like a bowl of spaghetti.

The fix (rebase before merging):

git fetch origin
git rebase origin/main
git push --force-with-lease
Enter fullscreen mode Exit fullscreen mode

Rebasing replays your commits on top of the latest main, giving a linear, readable history. Always rebase on your feature branch — never rebase a shared branch.


7. I committed a huge file and the repo is now 500MB

Someone committed a 200MB video. Now every clone is slow.

The fix:

git filter-repo --strip-blobs-bigger-than 10M
git push --force
Enter fullscreen mode Exit fullscreen mode

This removes large blobs from history. Going forward, add the file to .gitignore and consider Git LFS for legitimately large assets.


8. I cherry-picked a commit and got confusing conflicts

Cherry-picking is fragile — it applies a single commit's diff, which may not apply cleanly if surrounding code changed.

The fix (understand what cherry-pick actually does):

git cherry-pick <sha>
# if conflicts:
git mergetool        # resolve manually
git cherry-pick --continue
# to abort and start over:
git cherry-pick --abort
Enter fullscreen mode Exit fullscreen mode

git cherry-pick --abort lets you bail out cleanly and rethink whether cherry-pick is even the right tool.


9. I deleted a branch I still needed

You ran git branch -d feature/old and realized you still needed it.

The fix:

git reflog                    # find the commit the branch pointed to
git checkout -b feature/old <sha>
Enter fullscreen mode Exit fullscreen mode

Even deleted branches leave a trail in git reflog. Find the SHA and recreate the branch pointing at it.


The pattern: git reflog is your safety net

Almost every "I lost my work" panic is solvable with git reflog. It records every HEAD movement, even after resets and deletes. Git is designed to be forgiving — work is rarely gone forever.

My daily safety routine:

  1. Commit early, commit often (small commits are easy to undo)
  2. Use --force-with-lease, never bare --force
  3. Before any destructive command, check git status and git stash if unsure
  4. Learn git reflog — it's the difference between panic and calm

If you found this useful, I keep a free collection of 68 browser-based developer tools (JSON formatter, regex tester, base64, JWT decoder, and more) — all client-side, no signup, no tracking:

👉 Free Tools Hub — 68 Tools

And for a complete Git reference, I put together two guides — a Git Workflow Checklist (47 commands for daily work) and a Git & GitHub Power User Toolkit (50 commands and workflows):

👉 Git Workflow Checklist · Git Power User Toolkit

💸 Launch deal: Use code DEV40 at checkout for 40% off any guide (limited to 100 uses).

What's the worst Git mistake you've recovered from? Drop it in the comments — I'm building a list of recovery stories.

Top comments (0)