Most Git disasters are not disasters. They are reversible states that look permanent because the terminal is quiet and the error message is cryptic. The tool keeps almost everything you do for months, so the commit you regret and the branch you "deleted forever" are usually a couple of commands away from coming back.
What follows are the ten mistakes beginners hit most often, paired with the recovery steps. Run them in order, read the output, and don't panic-clear your working directory before you've had a look at what's recoverable.
You finished a feature, staged it, committed, and then noticed the prompt says main instead of feature/login. This is a two-step fix, and the order matters.
If the wrong-branch commit is unpushed and you simply want it gone with the changes still staged, git reset --soft HEAD~1 is gentler: it deletes the commit and leaves your edits in the index, ready to commit again on the right branch.
Be careful with --hard on a shared branch. If main is already on the remote, don't rewrite it — reverse the commit with git revert <hash> instead, which adds a new commit rather than deleting history other people may already have.
If the commit has not been pushed, you can edit it. Remove the file from tracking while keeping it on disk, then amend:
git rm --cached .env
git commit --amend --no-edit
Add the file to .gitignore in the same commit or the next one, otherwise Git will keep offering it back.
If the commit has been pushed, editing the commit is only half the job. Treat any credential that reached a remote as exposed: rotate the key or token first, then clean history if your team agrees it's worth the disruption. For a large binary that's already in history, tools like git filter-repo handle the rewrite, but that is a coordinated operation with your team, not a solo cleanup.
Conflicts everywhere, nothing committed yet: git merge --abort puts you back exactly where you started. Same idea for a rebase that has turned into a nightmare: git rebase --abort.
Git saved the pre-merge state for you. git reset --hard ORIG_HEAD returns the branch to where it was before the merge. If you only want to back out the merge while keeping your uncommitted work, git reset --merge ORIG_HEAD is the safer option.
If the bad merge is already published, revert it: git revert -m 1 <merge-hash>. The -m 1 tells Git to keep the first parent — the branch you merged into. Do note that re-merging the same branch later won't bring its commits back automatically; you'll need to revert the revert first. That quirk has confused better developers than you.
Deleted a branch with unmerged commits? Git's reflog remembers where it pointed.
git reflog
Scan the left column for the commit you lost, then recreate the branch at that hash:
git switch -c recovered-work <hash>
Reflog entries stick around for 90 days by default, so you have time. If the reflog has been pruned, git fsck --lost-found can list dangling commits that were never attached to a branch.
That "You are in 'detached HEAD' state" warning means you checked out a commit rather than a branch. Any commit you make there belongs to no branch and disappears from view once you leave. Save it with git switch -c experiment <hash>, or abandon it with git switch main.
Someone — possibly you — ran git push --force and flattened commits that were on the remote. The recovery depends entirely on whether a copy still exists locally.
Force-with-lease refuses the push if the remote has moved since your last fetch, which catches exactly the situation where you'd overwrite someone else's work. Make it a habit, and protect shared branches on the hosting side so nobody can force-push to main at all.
git checkout -- file or git restore file discards uncommitted edits with no confirmation. If the file was ever staged, you can often get it back: staged content lives in the object database, so git fsck --lost-found may surface the blob, or your editor's local history feature might have it. If it was never staged and never committed, there is nothing for Git to recover — this is why committing small and often beats committing perfectly.
Two more that catch beginners: git reset --hard throws away uncommitted changes along with the commits, and git stash is easy to forget. Run git stash list periodically; an old stash you thought was lost is usually sitting right there.
Before any risky command — reset, rebase, force-push — run git status and git log --oneline -5. Know what you're changing. If the operation feels large, create a safety branch first: git branch backup-before-rebase. It costs nothing and gives you a named, obvious place to return to.
In a throwaway repository, deliberately make each mistake: commit to main, reset --hard, delete a branch with -D, force-push over a commit. Then recover each one using the reflog. Doing this once, calmly, means that when it happens in real work you'll recognize the shape of the problem instead of guessing at commands.
Git isn't asking you to be careful every second. It's asking you to know where the undo button is — and now you do.
Photo: MART PRODUCTION / Pexels
A practical walkthrough for planning your sections, writing semantic HTML, styling a responsive layout with modern...
A practical comparison of local coding meetups and online communities on feedback, networking, access and...
A practical guide to Advent of Code: how the December puzzle event works, how to handle its uneven difficulty, and...
Fuel your passion for coding and development.
