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.

Is it ok to continue on a branch if you also merge back main into it? Like, branch gets merged into main on remote, local main pull, local merge main into local branch, push branch?

So this workflow is needed if you are working on a public, i.e. multiple devs collaborating on a single branch, scenario. But it is much better to avoid this as much as possible. Usually it is a ‘scoping’ issue, where you create a branch that is too broad. For example ‘api-for-frontend’, which is a massive thing.

In our org we prefer to delete the branch after merge. In a way it says ‘this branch is closed’. This is to encourage devs to define smaller and more logically scoped branches.

I want to take this opportunity to say that, branch is just a label on a commit, with some additional functions. Once you start focus on commits and lineage of the commits, then branches become some what irrelevant.

Aha. I was part of a project where each dev had their own long running branch for non-specific work and this was the norm, but it always felt clunky. And often resulted in merge issues.

That is a very weird setup. I have no clue why that flow is needed in the first place. Branches should be something disposable easily. What was the logic behind the setup? Any idea?