I think there's an easy compromise with `git describe`. `git describe` gives you a mix of tags and commit information to easily describe every commit to a build tool, but not need to setup a "CI tagger". If the commit has (an annotated) tag, `git describe` returns the tag name. If the commit isn't directly tagged, it returns `{nearesttag}-{commit count after that tag}-g{prefix of commit hash}`. Such as `v1.2.3-4-g01abcd`.

You can pass a `git describe` directly to just about any git command that takes a "commitish", so can copy and paste it directly to `git switch` or `git checkout` just as you would with a full hash. Except you also have prefixed human-readable version information that you can update.

About the only complaint with `git describe` is that if you are presenting these version numbers in semver scenarios and want the best semver ordering you want to replace that first "-" with a "+" and the second "-" with a ".", which aligns it better with semver's optional build metadata rather than looking like a semver pre-release.