Maybe a better way to track the release history of a Git repo
hellerve
33 points
8 comments
October 13, 2026
Related Discussions
Found 5 related stories in 98.3ms across 9,386 title embeddings via pgvector HNSW
- The Git history command deserves more attention turbocon · 179 pts · July 14, 2026 · 67% similar
- Git at Any Scale meetpateltech · 30 pts · August 18, 2026 · 53% similar
- Git-bug: Distributed, offline-first bug tracker embedded in Git alentred · 325 pts · September 25, 2026 · 51% similar
- Show HN: Git-knife – Edit commit messages, authors, and dates like a spreadsheet YonathanTesfaye · 146 pts · August 11, 2026 · 50% similar
- Committing to Git: Rebuilding ReadMe on Git gkoberger · 11 pts · July 21, 2026 · 49% similar
Discussion Highlights (4 comments)
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.
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.
teamolHuang
Complicated and unintuitive. Our company has a few dozens of different project repos. I just created a repo for storing deploy manifests (versions, etc. for every repos of a product), and then let our automation pipeline commit the manifest. Simple to follow and no source-unrelated crap in source repos.