One Git ref instead of thousands: a better way to track release history
Maybe a better way to track the release history of a Git repo
A former ZipRecruiter engineer describes how their Git monorepo accumulated thousands of release tags, slowing down everyday operations. He proposes storing deployment history as a linked list of metainfo commits, each with two parents: the actual release commit and the previous metainfo commit. This uses Git's native history mechanism, requiring just one ref per app and tier, making queries like 'when did we last deploy to production?' trivial with standard git log commands.
Git is well-designed for handling thousands of commits, but not for handling thousands of refs.
- 1718627440
You can kind of arrive at the same solution, without actually thinking about all this, by just merging into a release branch when making a release.
- lijok
Or commit a file to main that represents a release and build your automations off that
- unsloppable
Cool and clever.
One question: what do you use your old refs for?
We just delete them when we get too many.