I've seen this post brought up as relevant regularly up till 2010.
You may have been lucky to avoid the dredges but SW industry in the 2000s was a copy-paste fest (not in the "copy from stack overflow" sense but as in "copy paste instead of creating a function"), PHP with SQL in templates and string concat queries all over the place, MVC was a revolution. I'm not saying this was everywhere just that it was very common.
I'm sure some wise guy will come up with retort that MVC was used in the 70s and what not, but my point is a lot of the industry discovered it with Rails and Django.
The way that we teach programming these days and languages/tools/frameworks just make some bottom tier mistakes from the past impossible (or very impractical). People often ignore this context when evaluating modern framework
It was really, really bad.
My second employer used CVS. Tags were fun back then -- each file was versioned separately so committing multiple files while a tag was in progress might result in only some of your changes making it into the tag. My big innovation there was to add a validation step to our build machine to ensure that the tag matched the state of the branch once the tag had finished, and add the tag to the build version number. Presto: we can actually see which code was built into that day's full build :).
At another job I had the misfortune to get to know Rational ClearCase.
There may have been small teams that didn't use SC in the 1990s, but this has absolutely been a basic best practice for decades.
more like 30, at least in a lot of the industry. Even just looking at open-ish systems, people were excited about SVN in what, 2000?, because they had been working with CVS for years, if not a decade or more, at that point.
And especially if you don't have to work with a team.
Is it possible to climb a mountain without equipment? Sure, but it's a lot more dangerous and it'll take you longer to reach your goal.
P.S.: A lot of you are confusing "complicated" with "difficult".
Since he's working alone, he can easily use the local backup feature of it, which allow to easily rollback to automatically made copies of files, diff and cherry pick between current and backups, etc ... It's basically done automatically for you.
As long as you save your project regularly and don't need to merge code with anyone, it can go a long way.
It only gets complicated if you try to do complicated things.
git add -A
With a capital A.You can try and convince me until you're blue in the face dude, but I've tried it and I just don't like it. End of story.
I don't much read my git-commit-comments but I think it is useful to write them.
I don't usually branch, at least at this stage of the project. Probably yes when I go to production when there is a need to fix bugs in the released version(s) without having to put all the latest code into it.
Even without branching commits are a good way to save the latest known good state I can easily go back to if things didn't work out.
I've used source control for all personal projects since, and it's in no way a burden. In fact, there have been another couple of instances since the first, where I would have lost a bunch of work without it.
That's very valuable even when solo, and worth typing a "commit" command once in a while.
You can create as many branches as you want and do all the experimentation you want.
When I stopped caring about committing and branching (something I’ve too long associated with pushing code, like reaching milestones) and started doing both as much as possible I really felt lots of freedom.
Instead of overthinking I can create parallel different approaches and see where they lead to. It’s amazing.
If you have a remote repo then, you can also have offsite backups. If you never branch, it's still massively worth it.
Are git commands obtuse and unfriendly, yes.
The problem is that git is not intuitive and isn't automatic. I've seen more people loose code to git than be saved by having their repo offsite.
There's really no reason to be surprised at all about this unless you're the kind of person who never did any programming before, like, 2010 and lack the imagination or knowledge to understand how programming could be done without it.
As someone who is on the other side and believes in the value of continuously growing one's skills, I want to convince people that Git has value in learning and using. More tools in our toolbelt makes us more effective craftsmen. Which the DF developer did get around to doing...
If you want the absolute simplest way to use git, just setup an alias to do:
alias gcmp="git add -A && git commit && git push"
Now all you need to do is run gcmp every time you're ready to log the new state of your codebase. How could it be simpler?git only becomes more complex as your needs become more complex. At which point I'd recommend using something like https://magit.vc/ which makes complex git operations far easier. The CLI can only take you so far effectively unfortunately.
That would have been the OS tool back in 1998.
If I switched to working with a team I'd definitely use git. But for just me, cvs is all I really need. The most complicated thing I do is probably tag a release or revert to a previous revision of something, which is pretty rare.
There are even git repos of 99% done .gitignore files for most needs [1], which is most of the setup work for a solo project.
Git is also incredibly simple on single person personal projects, just git init, git add, git commit and some way to view the history and pending changes (either the command line, or most editors have a built in viewer).