Yeah that would be free if you have all the CI stuff set up.
Maybe she doesn't, though. At a previous job I logged build IDs and never ended up needing them because we were able to uphold a Git-first process pretty well
Yeah that would be free if you have all the CI stuff set up.
Maybe she doesn't, though. At a previous job I logged build IDs and never ended up needing them because we were able to uphold a Git-first process pretty well
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.