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?

Same… My usual strategy: rebase, if conflict abort and merge, if no conflict continue; merge always with explicit commits to master / main (no fucking squashing); keep task references in branch names and commit messages.

Same, but typically I will just resolve the conflicts during the rebase. Makes for cleaner commit history. Merge commits are for combining multiple big unrelated pieces of work together, where rebasing would be too annoying (let’s say 100s of commits each).

In my cases I have to solve same code conflicts multiple times during a rebase, so I just don’t try them when hit with conflicts

In my cases I has to solve same code conflicts multiple times during a rebase, so I just don’t try them when hit with conflicts.

Yeah if you have two branches, both with a bunch of commits which all modify the same areas of code, and reordering the commits doesn’t help, I can see how it is easier to merge.

I fail to see the benefits of “clean” git history

Well, if the commit history is clean and mostly linear, it’s much easier to read, understand and review. git blame will also be much nicer which is really important for debugging big codebases. Of course it’s a tradeoff, as usual.