Git tagy a sémantické verzování: co znamená v1.0.15 a jak správně verzovat

Každá knihovna na GitHubu má verze jako v1.0.15 nebo v6.4.2. Co ta čísla znamenají, kdo je určuje a proč po 1.0.9 nenásleduje 1.1.0, ale 1.0.10? V tomto článku vysvětlím Git tagy, standard sémantického verzování (SemVer) a ukážu, jak verze vydávají profesionální projekty.

Tento článek navazuje na díly Co je Git a jak funguje a Git workflow.

Verze je Git tag

Začněme odpovědí na hlavní otázku: verze jako v1.0.15 je obyčejný Git tag. Tag je pevný, nepohyblivý ukazatel na konkrétní commit. Zatímco větev se posouvá s každým novým commitem, tag navždy říká: "přesně tento stav kódu je verze 1.0.15".

# Annotated tag (doporučený pro verze)
git tag -a v1.0.15 -m "Release 1.0.15: oprava výpočtu dopravy"

# Tagy se na server posílají zvlášť!
git push origin v1.0.15

Častá chyba začátečníků: tagy se příkazem git push neposílají automaticky. Musíte je pushnout explicitně, jednotlivě nebo hromadně přes git push --tags.

Lightweight vs. annotated tag

Git zná dva typy tagů. Lightweight (git tag v1.0.0) je jen jméno ukazující na commit. Annotated (git tag -a) je plnohodnotný objekt s autorem, datem a zprávou. Pro vydávání verzí vždy používejte annotated tagy.

Sémantické verzování: MAJOR.MINOR.PATCH

Formát čísel není náhodný. Řídí se standardem Semantic Versioning (semver.org), kterým žije celý open source svět:

        v 1 . 4 . 15
        │   │   │
        │   │   └── PATCH: opravy chyb, nic nového
        │   └────── MINOR: nová funkce, zpětně kompatibilní
        └────────── MAJOR: změna rozbíjející zpětnou kompatibilitu

Prefix v je jen konvence pro pojmenování Git tagů, samotná verze je 1.4.15.

Kdy zvednout které číslo

Typ změny	Příklad	Z verze 1.4.15 vznikne
Oprava chyby	Špatný výpočet DPH	`1.4.16`
Nová funkce	Nová metoda v API	`1.5.0`
Breaking change	Přejmenovaná metoda	`2.0.0`

Při zvednutí čísla se nižší čísla nulují: z 1.4.15 po nové funkci vznikne 1.5.0, ne 1.5.15.

Co tedy znamená v1.0.15

Že od vydání verze 1.0.0 proběhlo patnáct opravných vydání a žádná nová funkce. A pozor, čísla nejsou desetinná: po 1.0.9 následuje 1.0.10 a klidně existuje verze 1.0.347.

Pre-release verze

0.4.2           → vývojová fáze před 1.0.0, API se může měnit kdykoliv
1.0.0-beta.1    → beta verze
1.0.0-rc.2      → release candidate (kandidát na vydání)

Pořadí: 1.0.0-alpha < 1.0.0-beta < 1.0.0-rc.1 < 1.0.0.

Proč na SemVeru závisí Composer a npm

Tady se ukazuje, proč je SemVer závazek a ne kosmetika. Když máte v composer.json:

{
  "require": {
      "symfony/console": "^6.4"
  }
}

zápis ^6.4 znamená: nainstaluj cokoliv od 6.4.0 do verze nižší než 7.0.0. Composer se podívá na Git tagy v repozitáři knihovny a vybere nejnovější vyhovující. Autor knihovny tím slibuje: minor a patch verze vám nikdy nic nerozbijou. Stejně funguje npm u JavaScriptu.

GitHub Releases

Z tagu lze na GitHubu vytvořit Release: stránku s popisem změn (release notes) a případně přiloženými soubory ke stažení. Platí: Release = tag + popis + přílohy. Pro Composer a npm stačí samotný tag, Release je nadstavba pro lidi.

Jak verzují profesionálové

Conventional Commits

Profesionální týmy píší commit zprávy ve standardizovaném formátu:

feat(checkout): přidání platby přes Apple Pay
fix(cart): oprava zaokrouhlování DPH
chore(deps): aktualizace symfony/console na 6.4.2
feat(api)!: nový formát odpovědi    ← ! značí breaking change

Kouzlo: z typů commitů jde automaticky odvodit nová verze. Samé fix zvednou PATCH, aspoň jeden feat zvedne MINOR a breaking change zvedne MAJOR.

Automatizované releasy

Velké projekty netagují ručně. Nástroje jako semantic-release nebo release-please po mergi do main samy projdou commity, spočítají novou verzi, vygenerují CHANGELOG, vytvoří tag i GitHub Release a publikují balíček na Packagist či npm. Celé to běží jako GitHub Actions workflow.

Ruční vydání verze krok za krokem

Pro vlastní projekt nebo knihovnu stačí jednoduchý postup:

# 1. Čistý a otestovaný main
git switch main && git pull

# 2. Aktualizace CHANGELOG.md
git add CHANGELOG.md
git commit -m "chore(release): příprava verze 1.5.0"

# 3. Annotated tag
git tag -a v1.5.0 -m "Release 1.5.0"

# 4. Push commitu i tagu
git push origin main
git push origin v1.5.0

# 5. Na GitHubu vytvořit Release s release notes

CHANGELOG.md

Seznam změn mezi verzemi podle standardu Keep a Changelog:

## [1.5.0] - 2026-06-11
### Added
- Platba přes Apple Pay

### Fixed
- Zaokrouhlování DPH u slevových kupónů

Nejčastější otázky o verzování

Musím začínat verzí 1.0.0?

Ne. Projekty ve vývoji běžně startují na 0.1.0. Verze 1.0.0 je signál: API je stabilní a od teď platí záruky SemVeru.

Jak smažu špatně vytvořený tag?

Lokálně git tag -d v1.0.0, na serveru git push origin --delete v1.0.0. Pozor, pokud si verzi už někdo stáhl, přepisování tagů způsobí zmatky. Lepší je vydat novou opravnou verzi.

Platí SemVer i pro weby klientů?

Pro běžný klientský web verzovat nemusíte, tam stačí historie commitů. SemVer dává smysl u všeho, na čem závisí jiný kód: knihovny, pluginy, API, interní balíčky.

Co znamená stříška a vlnka v composer.json?

^1.4 povoluje vše do <2.0.0 (nové funkce ano, breaking changes ne). ~1.4.0 povoluje jen opravy do <1.5.0.

Shrnutí

Verze v1.0.15 je Git tag ukazující na konkrétní commit a její čísla se řídí SemVerem: MAJOR pro breaking changes, MINOR pro nové funkce, PATCH pro opravy. Na tomto slibu stojí Composer i npm. Profesionálové dnes verze negenerují ručně, ale automaticky z Conventional Commits. Tím se kruh uzavírá: dobré commity z prvního dílu a kvalitní workflow z druhého dílu jsou základ, ze kterého verze vznikají samy.

Řešíte vývoj, nasazování nebo výkon svého webu? Ozvěte se mi.

Další články