Well well well.
Well well well.
I’ve had juniors who didn’t believe this, so just to say it: If you know what you’re doing, practically any Git problem is recoverable.
The one major exception is if you delete your local changes before committing them.
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.
I’m fed up with these two. Yesterday I had to cherry-pick to solve a combination of these two.
Specifically screwing up rebase. It is recoverable, but very annoying.
WDYM? Typically git rebase --abort will “just work”. If you have specifically done something really wrong, just look into git reflog
Pushing your commit without fetching
Git won’t allow you to do that if you set up your server properly. It will force you to pull first. I have [pull] rebase = true in my settings so that it always rebases my commits instead of merging them, which makes for much cleaner history.
Continuing on a branch even after it was merged.
This generally shouldn’t be a problem, you can just rebase the branch afterwards and it will be fine (the common commits will typically just be dropped).
The problem is not when I have to rebase. I know how to handle it. But with juniors they approach us only when things are in a really bad situation, where they cluelessly applied some commands they found on internet or from an LLM. Then it is very annoying to sit down and untangle the mess they created.
And regarding the pushing without fetching, it is usually a different branch. So they won’t incorporate the new changes in the main branch into their working branch, but just push their work into a branch. Again not a big deal. Just annoying.