This is not about mistakes in the Git-managed code. This is about mistakes in the Git commands themselves. Anything that involves merging/rebasing/conflict resolution can potentially be botched. These mistakes are usually fixable, but:

1. Fixing it requires some Git proficiency behind the level of the common Git user.
2. If you don't catch it in time, and only find the mistake when it's deep in your layers of Git history - well, good luck.

You're confusing errors in your code, and errors while doing some git command you thought you knew. Lucky you, it's clearly never happened to you because you don't mess around with it.

3. (3) Get annoyed by constantly increasing Code Coverage Requirements on untestable (often legacy) code. Even afding comments requires code coverage go up! Line must always go up!
4. Change step 2 to "Commit and push ONLY when absolutely necessary. Because adding comments often requires a rewrite of untestable code."
5. Go back to Step 2 and wait for a major bug.

Yeah.But many of them are extremely annoying. Specifically screwing up rebase. It is recoverable, but very annoying.

That said I have seen juniors make two other common mistakes.

1. Pushing your commit without fetching
2. Continuing on a branch even after it was merged.

I'm fed up with these two. Yesterday I had to cherry-pick to solve a combination of these two.

Fun fact! If you added a file but never committed it you can still recover it with git fsck --lost-and-found. The changes were still added to the git object store, and by grepping through the dangling blobs you can find the object containing the changes you care about.

Does deleting the repo off disk and redownloading from remote considered recovering? If so I'm a git expert.

Special shout out to the person who committed a gigabyte memory dump a few years ago. Even with a shallow clone, it's pretty darn slow now.

If you want to be the team's hero, I've had good luck removing old commits using git filter repo.

https://hibbard.eu/erase-sensitive-files-git-history-filter-repo/

We can't rewrite history to remove it since other things rely on the commit IDs not changing.

Oh right. Oof.

I would be working to arrange an accident for those other things. Those other things probably need to be retired.

Sounds like a flawed workflow, if this didn't go through at least code review. Was it committed directly to master?

Curious to know what kind of system relies on hashed not changing? Technically the hashes don't change, but a new set of commits is made. The history diverges, and you can still keep the old master if you need it for some time, even cherry pick patches to it..

The guy at work who managed git before me, well didn't quite have the knowledge I do and was not using LFS. In one of the main repos a 200mb binary was pushed 80+ times. This is not the only file that this happened to. Even if you do a shallow clone, you still need to add the commit depth eventually. It's a nightmare.

Been using it for over a year now and not being scared of trying operations is such a boon. It helps so much with learning when you know you can just roll back to an earlier state.

I've had zero issues with it so far and no one at work noticed anything different, other than there being a bit more rebase spam on PRs.

That is so cool. Why doesn't git have this already?

git re-flog is what you do with those idiots who mess up the repo so that someone else has to come in and fix it again.

Don't be afraid of rebases, they are an essential tool in Git.

This particular fear can only be addressed by understanding.

…button