[ryeguy_24]

I’ve seen so much content on the Internet dedicated to how hard Git is to understand the moment you get beyond basic functionality. Is Git the problem or is meant to be used only after months of training and practice? Seems silly to have any software take so long to learn and comprehend.

[112233]

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.

[nottoohard]

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.)

[mrkeen]

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.

[SJC_Hacker]

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.