Git is especially prone to the sort of confusion where all the experts you know use it in slightly different ways so the culture is to just wing it until you're your own unique kind of wizard who can't tie his shoes because he favors sandals anyhow.
Git is especially prone to the sort of confusion where all the experts you know use it in slightly different ways so the culture is to just wing it until you're your own unique kind of wizard who can't tie his shoes because he favors sandals anyhow.
The solution is to set team/department standards inside companies or use whatever you need as a single contributor. I saw attempts to standardize across a company that is quite decentralized and it failed every time.
This is ultimately where, and why, github succeeded. It's not that it was free for open source. It's that it ironed out lots of kinks in a common group flow.
Git is a cultural miracle, and maybe it wouldn't have got its early traction if it had been overly prescriptive or proscriptive, but more focus on those workflows earlier on would have changed history.
Unlike calculus, though, you can learn enough about Git to use it usefully in ten minutes. Maybe this sets people up for disappointment when they find out that afterwards their progress isn't that fast.
Ane example of that is the suckless philosophy where extra features comes as patches and diff.
(I started using Git in 02009, with networking strictly over ssh and, for pulls, HTTP.)
What? Knowing that a git repo is just a folder is nowhere near "expert" level. That's basic knowledge, just like knowing that the commits are nodes of a DAG. Sadly, most git users have no idea how the tool works. It's a strange situation, it'd be like if a majority of drivers didn't know how to change gears.
You are simultaneously saying that something is not expert level knowledge while acknowledging that most people don’t know it. Strange.
I'm not sure that's true, unless you only take certain parts of the world into consideration.
If you literally can't change gears then your choices are a) go nowhere (neutral), b) burn out your clutch (higher gears), or c) burn out your engine (1st gear). All are bad things. Even having an expert come along to put you in the correct gear once, twice, or even ten times won't improve things.
If a programmer doesn't know that git is a folder or that the commits are nodes of a DAG, nothing bad will happen in the short term. And if they have a git expert who can get them unstuck say, five times total, they can probably make it to the end of their career without having to learn those two details of git.
In short-- bad analogy.
> just like knowing that the commits are nodes of a DAG
Hello gatekeeping! I have used Git for more than 10 years. I could not explain all of the ins-and-outs of commits, especially that they are "nodes of a DAG". I do just fine, and Git is wonderful to me. Another related example: I would say that 90%+ of .NET and Java users don't intimately understand their virtual machine that runs their code. Hot take: That is fine in 2025; they are still very productive and add lots of value. > Have you never used rebase or cherry-pick?
Of course. And when I forget how to do it, I ask Google, or ChatGPT. It works for me.