Just happened with my team yesterday. We've a relative fresher in our team and he was told to develop a functionality, an important one. He completed all the work in 2 weeks time and we'd to deploy that code that day. I happened to pass by him and was helping him with changes which he'd to do when he pulled the latest version of that branch. He being a newbie did not once commit the code ( not even to local) during that 2 week's time. There was one point where we discussed to undo all the recent changes he made after the pull. Little did I know he has not commited the code ever. I quickly RESET the head and whooopp all his 2 week's effort was gone. We realized if after a while and both were in shock. Now he's developing the functionality from scratch.

If you are using Windows check twice folder/file name's case. If you committed and server now has 2 files file and File...

...Good Luck and let the Force be with you!

Worst situation I got into was corrupting the repo to the extent the Bitbucket admins needed to restore it. I forget the details of the workflow that led to it, but the solution was adding git prune to my update script to avoid dangling blobs. That is - instead of running git pull I run a script which pulls and prunes master, then offers to merge if I was working on a branch.

tldr: run git prune once in a while ;)

I know it's not "cool" to say it, but I regularly find people can clean up the mess much faster by redoing the changes on a fresh clone; and learning a cleaner workflow to avoid the problem in future. It often takes hours with two people pairing (the git guru and the git newbie) to unpick the mess, then you have to learn the clean workflow anyway. Basically - remember to do a cost/benefit analysis.

Also never EVER try to start your cleanup efforts on the only existing branch with the work you're trying to save. Push that existing branch somewhere (no matter how broken it is), make a fresh branch and work on the fresh branch. Because it often takes a few goes to get back to a clean state; and you can always delete those backup branches later.

I almost merged a branch in that had 900 files changed. Big disaster considering I only changed 5 files. It was hard to figure out where my branch got fudged up so I just grab the files I knew I changed and created a new feature branch. 😂 noob

I once wrote a couple of html files and after a few decided to shorten what was a very tedious process by using pug. Pug however doesn't return a pretty html file but a single line html string, so git obvisously got the file changes wrong (it was my fault of course, but still). That was messy.

git reflog can save lives. Sometimes. It's useful when something goes wrong when you commit, and it does not appear in your commit log.

I just had a very strange one

git status
resources/assets▒js/components/Compoent.vue: Protocol error

Ended up deleting the .git folder and start a new git repo since it was a small project and just went from dev to final release.

Long ago, spent more than a few hours trying to hunt down commits where bugs got introduced. Then learned git bisect. Things are better now.

http://webchick.net/node/99

Deleted a completed feature once. Branch + PR. 7 hours of hard work got wasted.

Then, I had no idea that something like this existed: http://stackoverflow.com/a/3640806

😁

In my initial days of job, I had once merged an unstable branch into the stable branch and had forgotten to unmerge it. :P

The code went into the production with "lorem ipsum". :D

Got a nice trashing from my manager! Lolz.

The positive side: I have started taking git things serious after that incident.