> because you treat everything as a series of patches from day 1.
That's an option, but not the only option.
For big shared mature projects, I treat each commit (to shared branches at least) as a presentation, where I try to describe exactly what changed, how, why, and to preemptively answer any questions I suspect will come up in the code review, clean up unnecessary or unrelated changes, cross linked to any task tracking items and bugs, the code review itself, any docs I might've updated in tandem, .... the description will often be longer than the actual code changes. With a quick summary to start, so you won't typically need to read the rest, of course. After the review and submit, I'll ping QA with some stuff I think might be worth testing once the build goes green. My commit messages, at least, tend to be better than any of my coworkers.
For solo seed projects, on the other hand, I take 5 seconds to try and describe what it was I did in the past X minutes. I try to remember to commit often enough that this doesn't devolve into "Changed stuff" because I forgot to commit for a day and touched 20 different things, but it happens - making those commits worse than any my coworkers generate, but still better than no VCS. They come in handy for tracking down bugs and such.
> The greatest works of humanity were written without a VCS (novels, operas). Using a VCS is only mandatory for multi-person projects.
Most of these had drafts and earlier revisions (or versions.) I agree that VCS is not mandatory mandatory, but the entire reason I switched to git (from SVN) was that "git init" is super low friction for getting new projects under VCS. That it handles branches way better and enables distributed workflows are mere side benefits.