In the brave new world of building and deploying every commit (Continuous Integration / Continuous Deployment, CI/CD), for every commit in your git repo, you need to build it, outputting a binary artifact, an executable or an entire container image. Now comes the problem: how do you organize and keep track of it?
Here's a list of ways to tag things:
latest: mutable tag, definition depends on time, race conditions for parallel builds
v1.2.3: not necessarily immutable, may change depending on time, tedious for every commit, litters git history
git rev-parse HEAD:
879cd74c89efdedd0693b4a7b8416321712c3a07: too long, doesn't sort well, requires the source repo to get any other info, eg age estimate
git rev-parse --short HEAD:
879cd74: shorter version of the above
v0.0.0-0.yyyymmddhhmmss-abcdefabcdef: sorts like semver, can incorporate tags, encodes both a time estimate (commit time) and git commit, only works for fully reproducible builds
v0.0.0-0.yyyymmddhhmmss-abcdefabcdef+buildid: same as above, but incorporates a build id (eg CI run), allows tracking down the provenance of the build.
Even with all of the above, if you're using containers,
nothing technically prevents you from modifying tags.
Instead you should consider also use image digests
and maybe store authenticated metadata in a separate artifact,
You may still want that tagging, so cleaning up old artifacts is easier...