Isn't that what git tags are for? Just create a tag with something human-readable like, I dunno, a version number would be good. And that way ANYONE can see the state of your sources for a given build.

If you use github release workflow, you don't even have a choice about it. You cannot create a release without creating a matching tag.

▲

01HNNWZ0MV43FF 5 days ago | parent [-]

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

	▲	WorldMaker 4 days ago \| parent [-]
		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.