You setting your theory against my lived experience. If you want to understand the situation more fully, you can read How To Destroy A Tech Startup In Three Easy Steps:
I did my best to re-create the extent to which decisions were driven by panic and the pressure of time.
Please note, every company in the world has a finite amount of time, and a finite amount of money. You can argue that a company should hire people with more experience, but people with more experience will be more expensive, so you will end up with less people. Or you can argue that a company should hire more people, of less experience, and then train them. Training takes time, so in this case you are trading time for money.
All of these strategies work, but in different circumstances. In the circumstances that I faced in 2015, described in the book, I advocated for the strategy of less people, of a higher skill level. I was, however, outvoted, which is a reality of corporate life.
It is relatively rare that a company follows an ideal strategy. What I see instead is constant course correction, often with a bit of a lag, so that the company ends up having the ideal strategy for dealing with the situation that it faced 6 months ago, which is not necessarily the ideal strategy for what it is facing now.
Business tends to be chaotic. The Platonic Ideal of computer programming needs to be adjust to the real realities that businesses face.
To be clear, Sital's attitude was a major problem, and myself and co-workers advocated that he be fired. But management kept him on, and I was given the responsibility of covering for the gaps in his knowledge. I was not happy about this, but this is a reality of business: we often have to accept that a decision has been made that we strongly disagree with, and then we need to somehow make the best of it.
The issue you have with git, is that untrained developers have a hard time using it. Which brings me back to my original comment. It really doesn't take long to train someone to use git. And you can choose whatever flow you want. That's the beauty of it. If the company hires lower skill people, you can just guide choose a branching mode suited for their needs. They don't even need to use branches. Or just teach them to use an UI. But please don't teach them SVN.
But please don't teach them SVN
Why would you say this?
You also say:
If the company hires lower skill people, you can just guide choose a branching mode suited for their needs
If the company has lower skill people, why not go with the technology that requires less skill? This seems like an obvious step.
"The issue you have with git, is that untrained developers have a hard time using it."
Please re-read my first post, up above, which started this thread. I wrote:
"But all of that stuff is trivial compared to the major flaw:
Graphic designers, writers, HTML/CSS frontenders, managers, data analysts and QA staff can’t use Git, even though they all used Subversion."
> Graphic designers, writers, HTML/CSS frontenders, managers, data analysts and QA staff can’t use Git, even though they all used Subversion.
Why is it hard for them to use git? For simple use cases, git can be as easy as commit & push. No need for branches. There are even UIs which allow you to easily make commits and see the log . If more people work together and conflicts arise, I honestly don't know how SVN is better at solving them.
All I can do is quote what you wrote in a different comment:
"If you're an artist, git is not for you."
Would it be the best if Sital never committed his changes?
That way he would not be able to hurt your project and you would be able to fire Sital sooner.