Jak fungují tagy a vydání (releases) v Gitu?

Question

Accepted Answer

**Tagy** označují konkrétní body v historii jako důležité — typicky **vydání (releases)** (verze jako v1.0.0). Na rozdíl od větví jsou tagy pevné ukazatele, které se neposunují, a používají se k označení a referenci verzí vydání. Jsou centrální pro správu verzování a vydání.

## Vytváření tagů

```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 "..."
```

**Anotované tagy** (doporučuje se pro vydání) ukládají metadata (tvůrce tagu, datum, zprávu); **lehké tagy** jsou pouze jménem odkazující na commit.

## Práce s tagy

```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
```

Důležité: **tagy se automaticky neodesílají** příkazem `git push` — musíte je odeslat explicitně.

## Tagy vs větve

```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.
```

## Sémantické verzování a vydání

```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.
```

## Proč na tom záleží

Pochopení tagů a vydání je cenné pro **verzování a správu vydání**, takže se jedná o užitečné praktické znalosti pro práci s vynechaným softwarem. **Tagy** označují důležité body v historii — typicky **verze vydání** (jako v1.0.0) — poskytují pevné, trvalé reference na konkrétní commity, což je nezbytné pro sledování a referenci toho, jaký kód tvoří každé vydání.

Pochopení rozdílu mezi **anotovanými tagy** (doporučuje se pro vydání, ukládajícími metadata jako tvůrce tagu, datum a zprávu) a lehkými tagy je praktickou znalostí pro správné označení vydání.

Znalost vytváření, výpisu a checkoutu tagů a důležité, že **tagy se automaticky neodesílají** (vyžadují explicitní `git push origin --tags` nebo odesílání konkrétních tagů — běžná chyba, kdy lidé vytvoří tagy, ale zapomenou je odeslat), je nezbytná pro správné spravování tagů vydání.

Pochopení **tagů vs větví** (tag je pevný ukazatel na konkrétní commit — trvalý štítek, který se neposunuje — zatímco větev je pohyblivý ukazatel, který se posunuje s vývojem) objasňuje jejich různé role: tagy pro trvalé označování vydání/milníků, větve pro probíhající práci.

Pochopení spojení se **sémantickým verzováním** (konvence MAJOR.MINOR.PATCH pro komunikaci povahy změn) a jak platformy budují **Vydání** z tagů (s poznámkami k vydání a artefakty pro distribuci) odráží, jak se tagy vešly do správy skutečných vydání.

Protože vydávání a verzování softwaru je běžná potřeba a tagy jsou mechanismem Gitu pro označování a referenci verzí vydání (centrální pro správu vydání a integrované s funkcemi vydání platforem), pochopení tagů a vydání — anotované vs lehké tagy, jejich odesílání, tagy vs větve a jejich role ve verzování/vydání — je cenné, prakticky relevantní znalosti Gitu pro spravování vynechaného softwaru, užitečný aspekt profesionálního vývoje spojený s konvencemi verzování a procesy vydání.