Tags are a Git feature, not a GitHub invention — they’ve existed since Git’s earliest versions as a simple way to give a permanent, human-readable name to a specific commit. Long before GitHub existed, developers used tags to mark version numbers like v1.0 or v2.3.1, giving themselves an easy way to return to exactly that point in history later.

Releases are GitHub’s contribution on top of that foundation. As software distribution moved online and GitHub became the default home for open-source and private projects alike, a plain Git tag wasn’t quite enough — users needed release notes explaining what changed, and often a downloadable, pre-built version of the software rather than raw source code. GitHub Releases were built specifically to answer that need, wrapping a tag with a rich, publishable page.

Imagine a team ships version 2.0 of their application. Six months later, a critical bug is reported specifically in that version, and the team needs to reproduce it using the exact code that was actually shipped — not whatever main happens to look like today, which has moved on considerably since then. Without a fixed marker, finding that exact historical state means digging through commit logs and guessing.

The core motivation for tags is permanence: a fixed, unambiguous reference to a specific commit that will never silently move, unlike a branch. The core motivation for releases, building on that, is communication and distribution: turning a raw, permanent commit reference into something a human user or downstream system can actually understand and use.

A tag is a named pointer to one specific commit, created once and — by convention and design — never moved afterward. Unlike a branch, which advances automatically as new commits are added, a tag stays fixed on the exact commit it was created against, forever.

A release is a GitHub-specific feature built on top of a tag, adding a publishable page with a title, formatted release notes describing what changed, and the ability to attach downloadable files — called release assets — such as compiled binaries, installers, or packaged archives.

Understanding how tags and releases relate architecturally clarifies why they behave the way they do.

The clean separation here matters: tags exist entirely within Git itself and remain fully functional even outside of GitHub — cloning a repository elsewhere still brings every tag along. Releases, release notes, and assets, on the other hand, are GitHub-specific and don’t transfer automatically if a repository moves to a different platform.

Here’s what happens internally when a team publishes a new release through GitHub.

flowchart LR
    A["Commit reaches\na stable point"] --> B["Git tag created\n(e.g. v1.2.0)"]
    B --> C["GitHub release\ncreated from that tag"]
    C --> D["Release notes\nwritten or generated"]
    C --> E["Assets uploaded\n(binaries, installers)"]
    D --> F["Release published"]
    E --> F
    F --> G["Users download\nsource archive or assets"]
    F --> H["CI/CD pipelines can\ntrigger from the new tag"]
    

Notice the fork at the bottom: a published release serves two distinct audiences simultaneously — human users browsing the Releases page to download something, and automated systems (like a deployment pipeline) that can react programmatically the moment a new tag matching a certain pattern appears.

Git supports two meaningfully different kinds of tags, and understanding the distinction matters for anyone working with releases seriously.

GitHub Releases work with either type underneath, but annotated tags are generally the better default for anything intended as an official, public version marker, precisely because of the extra metadata and optional signing they support.

While Git and GitHub don’t enforce any particular naming scheme for tags, an overwhelming majority of projects follow semantic versioning — a widely adopted convention that encodes meaning directly into the version number itself.

Because tags and releases are meant to represent a trustworthy, permanent historical record, a few reliability factors are worth understanding clearly.

• Tags are conventionally immutable, but not technically unmovable. Git allows a tag to be force-moved to point at a different commit, which is almost always a bad idea for anything already published, since it silently breaks the “permanent reference” guarantee everyone assumes.
• Deleting a release doesn’t automatically delete its underlying tag. These are separate objects, and cleaning up one without the other can leave inconsistent state behind.
• Auto-generated source archives are dynamically created, not stored files. GitHub generates the zip and tarball downloads for a tag on demand, meaning they always accurately reflect that tag’s exact commit.
• Draft releases are not publicly visible until published. This allows a team to prepare a release fully, including assets and notes, without prematurely exposing it before it’s ready.

Tags and releases also carry genuine security implications, particularly for widely distributed software.

• Signed tags provide authenticity verification. A GPG-signed annotated tag lets downstream users cryptographically verify that a release genuinely came from a trusted source, rather than an impersonated or compromised account.
• Release assets should be checksummed. Publishing checksums (or signatures) alongside binary assets lets users verify a downloaded file hasn’t been corrupted or tampered with.
• Supply-chain risk increases with unpinned tag references. Automation or dependency configurations that reference a tag rather than a specific commit SHA can be exposed if that tag is later force-moved to different, potentially malicious content.
• Release permissions matter. Only trusted collaborators with appropriate repository permissions should be able to publish releases, since a malicious or compromised account publishing a fake release could distribute harmful software under a trusted project’s name.

Tags and releases integrate deeply with automated pipelines, often serving as the trigger point for an entire deployment or publishing process.

• Use annotated, signed tags for anything officially released. Reserve lightweight tags for casual, personal, or throwaway markers only.
• Follow semantic versioning consistently across the project’s history. This keeps both humans and automated tooling able to reason reliably about what a given version number actually means.
• Never force-move a tag that’s already been published or downloaded by others. Treat published tags as permanently immutable, no exceptions.
• Write meaningful release notes, ideally combining auto-generation with a short human-written summary. Auto-generated pull-request lists are useful, but a brief human summary of the release’s overall significance adds real clarity.
• Publish checksums or signatures alongside binary release assets. This lets downstream users verify integrity and authenticity before trusting a downloaded file.