Training won't help: you need to be fighting wild git beasts almost daily, otherwise it all evaporates. Any modern dev work takes up 500% of your brain already. You pull, push, commit and stash all the time and it becomes second nature.

Then, suddenly: your stash pop has failed! Something has been left somewhere! You need to git add something! Output of git diff is empty! Why is it empty, did stash not apply at all? (you run git stash pop second time, and feel terror) It recomends you to run git restore --staged! Was restore not kinda reset that wipes your local changes? Stash was your safe space, the only git thing you felt sure about. You feel abandoned.

Next time, build script breaks only for you! No idea why! Turns out a day later the script cannot deal with worktrees you set up last year when you tried to "learn git"

Some time later lead emails about "scrubbing prod creds", "force pushing HEAD". You run attached commands with fear and awe.

Next month, you end up with a detached head! It sounds painful! Half stuff does not work!

Gradually you are being conditioned that git equals pain. Sure, other tools have it worse (hi ffmpeg!), but they don't spring it on you in a middle of a big change you are trying to keep in your head, only to be forced to take a sabbatical and learn seven circles of reset because a wild tag merge conflict has appeared, or your lead wants you to use rerere to rebase your branch after splitting one commit into three.

Hey, so, these are not problems unique to git, for what it's worth. And if people don't want to deal with problems, then maybe software development isn't for them, because this is like a plumber complaining about joining pipes. (And don't bother belaboring this analogy, because I will not respond.)

No, it's like plumber complaining about filling tax return forms. In the middle of joining pipes. (And I will bother belaboring your analogy. For the benefit of others reading it.)

As you say, it is not unique to git. Bug trackers, system updates etc. also can "disrupt flow" and take a lot of attention away from the main work. But git is unique in the insidious way that it springs such hard problems on unsuspecting developers that are busy *actually working*

Git is there for tracking changes. If you don't care about that, then there's nothing to be done. If you do care about it and it's important for your job, you learn the tool and use it. And git is a good tool.

Git is a good tool for tracking changes if your primary job is tracking changes. It is terrible tool if you care about tracking changes because you need your work done. There is no encapsulation and the cognitive load and amount of moving parts you need to keep track of mentally is hugely distracting.

It's just the realities of participating in a distributed system. There's no 'current state' or 'now'.

You could make the mental model easier to understand by centralising the state and switch to pessimistic locking instead of optimistic. But then you'd have to live with the downsides of those, like git's predecessors.

There's definitely a local "current state". Its just that there's no inherent concept of a central repository or source of truth.

In practice most people use it as if it does - the remote is "preferred". Which isn't such a bad thing if you know how to use branches and resolve conflicts properly.

Best practice is to create a new branch for each feature, then create a PR into the proper branch.

Early on in development it can be very chaotic as so much code is changing so quickly. No revision system is going make up for a lack of communication and division of responsibilities.