Hvordan fungerer tags og releases i Git?

Question

Accepted Answer

**Tags** markerer specifikke punkter i historikken som vigtige — typisk **releases** (versioner som v1.0.0). I modsætning til branches er tags faste pegepinde, der ikke bevæger sig, og bruges til at mærke og referere til releaseversioner. De er centrale for versionering og releasestyring.

## Oprettelse af tags

```bash
# annotated tag (recommended for releases — has metadata: tagger, date, message)
git tag -a v1.0.0 -m "Release version 1.0.0"

# lightweight tag (just a pointer, no metadata)
git tag v1.0.0

# tag a specific past commit
git tag -a v1.0.0 <commit> -m "..."
```

**Annoterede tags** (anbefalet til releases) gemmer metadata (tagger, dato, besked); **lettvægts-tags** er blot et navn, der peger på en commit.

## Arbejde med tags

```bash
git tag                        # list tags
git show v1.0.0                # show a tag and its commit
git checkout v1.0.0            # check out the code at a tag (detached HEAD)

# tags are NOT pushed by default — push them explicitly:
git push origin v1.0.0         # push a specific tag
git push origin --tags         # push all tags
```

Vigtigt: **tags pushes ikke automatisk** med `git push` — du skal pushe dem eksplicit.

## Tags vs branches

```text
BRANCH → a MOVABLE pointer that advances as you commit (ongoing development)
TAG    → a FIXED pointer to a specific commit (a permanent label — doesn't move)
→ Use tags to permanently mark releases/milestones; branches for ongoing work.
```

## Semantisk versionering og releases

```text
SEMANTIC VERSIONING (SemVer): MAJOR.MINOR.PATCH (e.g. v2.3.1)
  MAJOR → breaking changes | MINOR → new features (compatible) | PATCH → bug fixes
→ Tags label these versions. Platforms (GitHub) build "Releases" from tags
  (with release notes, built artifacts) for distribution.
```

## Hvorfor det betyder noget

At forstå tags og releases er værdifuldt for **versionering og releasestyring**, så det er brugbar praktisk viden for arbejdet med udgivet software. **Tags** markerer vigtige punkter i historikken — typisk **releaseversioner** (som v1.0.0) — og giver faste, permanente referencer til specifikke commits, hvilket er essentielt for at spore og referere til, hvad kode der udgør hver release.

At forstå skellet mellem **annoterede tags** (anbefalet til releases, gemmer metadata som tagger, dato og besked) og lettvægts-tags er praktisk viden for korrekt releasemærkning.

At vide, hvordan man opretter, lister og checkouter tags, og især at **tags ikke pushes automatisk** (kræver eksplicit `git push origin --tags` eller push af specifikke tags — en almindelig faldgrube hvor personer opretter tags men glemmer at pushe dem), er nødvendigt for korrekt styring af releasetags.

At forstå **tags vs branches** (et tag er en fast pegepind til en specifik commit — et permanent mærke, der ikke bevæger sig — mens en branch er en bevægelig pegepind, der skrider frem med udviklingen) præciserer deres forskellige roller: tags til permanent markering af releases/milepæle, branches til løbende arbejde.

At forstå forbindelsen til **semantisk versionering** (MAJOR.MINOR.PATCH-konventioner for at kommunikere arten af ændringer) og hvordan platforme bygger **Releases** fra tags (med udgivelsesnoter og artefakter til distribution) afspejler, hvordan tags passer ind i rigtig releasestyring.

Da udgivelse og versionering af software er et almindeligt behov, og tags er Git-mekanismen til at markere og referere releaseversioner (central for releasestyring og integreret med platformes releasefunktioner), er det værdifuldt, praktisk relevant Git-viden at forstå tags og releases — annoterede vs lettvægts-tags, at pushe dem, tags vs branches, og deres rolle i versionering/releases — for styring af udgivet software, et brugbart aspekt af professionel udvikling forbundet med versioneringskonventioner og releaseprocesudviklinger.