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.

  • Pushing your commit without fetching
  • 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.

    Maybe I’m just a wizard, or I don’t know what y’all are talking about, but rebases aren’t special. If you use ’git reflog’ it just tells you where you used to be before the rebase. You don’t have to fix anything, git is append only. See where the rebase started in reflog, it’ll say rebase in the log line, then ’git reset --hard THAT_HASH’

    Pushing without fetching should be an error. So either they got the error, didn’t think about it, and then force pushed, or someone taught them to just always force push. In either case the problem is the force part, the tool is built to prevent this by default.

    Continuing after merge should be pretty easy? I’d assume rebase just does it? Unless the merge was a squash merge or rebase merge. Then yeah, slightly annoying, but still mostly "rebase -i’ and then delete lines look like they were already merged?

    Continuing on a squash merged branch is very annoying, and I had to deal with this in one repo regularly… Luckily I was annoyed enough to research about this and found out about rebase --onto “main merge commit” “branch merged commit”.