I disagree with the build system providing this. Only because I've watched people trying to do it right for 20 years and failing miserably. This culminated in the turd that is semantic versioning which is almost always universally poorly implemented and of no use whatsoever to the end user or any internal team past the desire to add complexity. Look back in the past and ask yourself, "does major version matter?". Eventually only the release version matters and that just has to be greater than the last release version. Add poorly implemented or NIH libraries to manage this and it's a world of hell. Imagine a piece of shit written in Groovy embedded in Jenkins by someone who left 2 years ago steaming away with a thousand edge cases waiting to blow. That's reality and it sucks.
You should never rewrite history. Git provides a lot of nasty stuff like that such as squash merges which it pretends is nothing to do with rewriting history but it is exactly and it's absolutely impossible to go back and blame who the hell did X, Y or Z and that is absolutely essential for audit.
A lot of people complain about Subversion but honestly it's probably the best solution out there still for large teams. The tools are good and understandable by mere mortals, the thing can have decent single-sign-on authentication without a ton of infrastructure, it's append only as far as the end user is concerned and every commit already has a monotonic incrementing ID. Now I'm going to get a "wait a minute, what about untracked merges" complaint here but that was never actually a problem because you can still epically fuck up any large codebase with merges using exactly the same method in git and incur exactly the same cost. Where people are doing work is a human issue. You can't have two teams refuctoring (misspelled intentionally) the same code regardless of the VCS. You are at the mercy of logical intent and diff not the VCS so stop pointing fingers at it.
I'm not even getting into the horrid side of git as well such as storing binary content or product composition, which by nature of it forces you to use external piles of crap like Artifactory and being bled dry by infrastructure software. Adding complexity to software delivery never results in any cost benefit.
I regularly work with 203 github repos, 40 MLOC of code and 160 engineers and it's a nightmare when you want to scale up a team like that.
Ergo for me:
Single user: learn and use Fossil.
Small team: One subversion repo for all projects. Lightweight branches.
Large team: lots of subversion repositories. Software composition via repo links. Light branches per repository.
really skilled team (rare): learn and use fossil.
Edit: mini rant on github. No one actually knows how to use git anyway. Teams should push upstream and then someone composes the product (think Linus and kernel etc) then that is published after it has gone through various pipelines. Every stage has their own repository and code flows between. But no along came some idiots and puked a pile of ruby into the universe which removes the distributed property of the entire VCS, which is its only benefit, and everyone starts circling that like flies around shit. It's wrong, broken and utterly stupid.