Topic
Everything filed under release-management, across every section.
A Git tag and a GitHub release can both say v1.2.3, yet represent different events with different dates and automation consequences. Build a semantic versioning workflow that separates source identity, release publication, prereleases, and GitHub’s latest-release label.
GitHub immutable releases protect published tags and assets, but they also remove your easiest recovery options. Use this pre-publication checklist to verify the commit, binary, checksums, release metadata, and rollback path before publication.
Use the GitHub Changelog as your source of record and a release-notes aggregator as an early-warning layer. This workflow shows how to triage Copilot, Actions, security, CLI, and Enterprise updates into ignore, review, test, or act-now decisions.
Turn release management into a repeatable, executable checklist with test evidence, named approvers, deployment ownership, measurable rollback triggers, and post-release verification.
A Git tag identifies a commit; a GitHub release turns that point in history into a downloadable, documented software delivery. Use this repeatable checklist to create release notes, attach verifiable assets, protect the release boundary, and inspect published releases with gh release view.
A Git tag can point to the right commit while a GitHub Release still points users at the wrong package. Learn the practical difference, then use gh CLI and Git commands to create, inspect, and verify a release with a checklist your team can repeat.