Main a Master Branch v Gitu: co to je a k čemu slouží hlavní větev

Co je Main / Master Branch v Gitu

Main Branch (nebo Master — v závislosti na nastavení úložiště) — je výchozí větev, která se vytváří při inicializaci jakéhokoli Git úložiště. Je to hlavní větev projektu a obsahuje kód připravený k nasazení do produkce.

Na rozdíl od develop, kde probíhá každodenní práce s novými funkcemi, je main výkladní skříní projektu. Každá verze kódu v main prošla celým cyklem: vývoj ve feature větvi, integrace v develop, příprava vydání v release větvi a finální testování. Teprve poté se změny dostanou do main.

Klíčový princip: main musí být vždy stabilní. Pokud je v main objevena chyba, znamená to neodkladný hotfix, který musí být vydán mimo pořadí. Proto je v profesionálních projektech main chráněn před náhodnými změnami pomocí branch protection rules.

Podle Git Book není main speciální větev s mimořádnými vlastnostmi, ale obyčejný odkaz na commit, který je podle konvence považován za hlavní. Git na systémové úrovni nerozlišuje mezi main a jakoukoli jinou větví.

Přechod z master na main

Historicky se výchozí větev v Gitu nazývala master. V červnu 2020 upozornilo hnutí Black Lives Matter na termíny master a slave v IT průmyslu. GitHub oznámil přechod na termín main pro výchozí větev.

Od října 2020 jsou všechna nová úložiště na GitHubu vytvářena s větví main. GitLab a Bitbucket také zavedly podporu main jako výchozího názvu. Git 2.28 (červenec 2020) přidal možnost init.defaultBranch pro konfiguraci názvu výchozí větve.

Technicky je přejmenování existující větve z master na main jednoduchá operace. Hlavní výzvou je aktualizace všech odkazů v konfiguracích CI/CD, dokumentaci a lokálních úložištích vývojářů.

Pro přejmenování větve v existujícím úložišti proveďte:

# Lokální přejmenování master na main
git branch -m master main

# Aktualizace vzdáleného úložiště
git push -u origin main

# Odstranění starého master na serveru
git push origin --delete master

# Aktualizace HEAD na serveru
# (přes webové rozhraní GitHub: Settings → Branches → Default branch)

Role main v Git Flow a GitHub Flow

Git Flow a GitHub Flow definují roli main větve odlišně. Výběr modelu závisí na velikosti týmu, frekvenci vydání a požadavcích na stabilitu kódu.

Pro vývoj mobilních aplikací je standardem Git Flow, protože publikování aplikací v App Store a Google Play má pevné cykly vydání. GitHub Flow je vhodnější pro webové projekty s možností nasazení několikrát denně.

GitHub Flow — zjednodušený přístup

V GitHub Flow neexistuje develop větev. Všechny feature větve se vytvářejí přímo z main a po dokončení se slučují zpět prostřednictvím Pull Request. Každé sloučení do main automaticky spouští nasazení do produkce. Tento model vyžaduje vysokou automatizaci testování a týmovou disciplínu.

V GitHub Flow neexistuje develop větev. Všechny feature větve se vytvářejí přímo z main a po dokončení se slučují zpět prostřednictvím Pull Request. Každé sloučení do main automaticky spouští nasazení do produkce. Tento model vyžaduje vysokou automatizaci testování a týmovou disciplínu.

Ochrana main větve

Branch protection pro main — povinné nastavení v každém komerčním projektu. Bez něj může náhodný push odeslat nedokončený kód do produkce nebo zničit fungující aplikaci pro všechny uživatele.

• Require pull request — přímý push do main je zakázán. Všechny změny přes PR s revizí.
• Require approvals — minimálně 2 schválení pro sloučení do main (v případě chyby jednoho recenzenta).
• Require status checks — všechny kontroly CI/CD musí být úspěšné před sloučením.
• Require up-to-date — PR musí být založen na nejnovějším commitu main.
• Include administrators — ochrana platí i pro vlastníky úložiště.
• Require signed commits — všechny commity v main musí být podepsány GPG klíčem.

Konfigurace všech šesti pravidel — standard pro mobilní projekty s publikem 10 000+ uživatelů. Pro malé projekty stačí první tři pravidla.

Srovnání úrovní ochrany pro různé typy projektů

Úroveň ochrany main závisí na rozsahu projektu. Startup si vystačí s minimální ochranou, zatímco enterprise aplikace vyžaduje maximální omezení.

Vydání a tagy v main

Tagování (tagging) — praxe vytváření pojmenovaných odkazů na konkrétní commity v main. Každý tag odpovídá verzi aplikace vydané do produkce. To umožňuje rychlé přepnutí na libovolné předchozí vydání pro ladění nebo opravu.

Standard pojmenování tagů ve vývoji mobilních aplikací — SemVer (Semantic Versioning): v1.2.3, kde první číslo je hlavní verze (breaking changes), druhé — vedlejší (nové funkce), třetí — patch (opravy).

Tag se vytváří po sloučení release větve do main. Tento commit je poté sestaven v CI/CD, podepsán a odeslán do obchodu s aplikacemi. Pokud je v tagu objevena chyba, vytvoří se hotfix větev z tohoto tagu.

# Vytvoření anotovaného tagu vydání
git tag -a v2.4.1 -m "Release version 2.4.1"

# Odeslání tagu na server
git push origin v2.4.1

# Zobrazení všech tagů v úložišti
git tag -l "v2.*"

# Vytvoření hotfix větve z konkrétního tagu
git checkout -b hotfix/crash-fix v2.4.1

Hierarchie větví Git Flow

Porozumění hierarchii větví v Git Flow — základ pro správnou organizaci společné vývoje. Každý typ větve má svůj zdroj, účel a pravidla sloučení.

• Main (úroveň 1) — kořenová větev, obsahuje pouze verze vydání. Vytváří se při inicializaci úložiště.
• Develop (úroveň 2) — vytváří se z main na začátku projektu. Obsahuje integrační kód všech funkcí.
• Feature (úroveň 3) — vytvářejí se z develop. Izolovaný vývoj jednotlivých funkcí.
• Release (úroveň 2) — vytváří se z develop. Příprava konkrétního vydání k publikaci.
• Hotfix (úroveň 2) — vytváří se z main. Neodkladná oprava kritických produkčních chyb.

Důležité pravidlo: feature se nikdy neslučuje přímo do main. feature → develop → release → main — správný řetězec sloučení. Porušení tohoto pravidla zbavuje celý model Git Flow smyslu.

Příklady příkazů pro práci s main

Zvažte scénář: tým dokončil přípravu vydání v2.5.0. Release větev byla zkontrolována a je připravena ke sloučení do main. Po sloučení se vytvoří tag a vydání je publikováno.

# Přepnutí na main a aktualizace
git checkout main
git pull origin main

# Sloučení ověřené release větve
git merge --no-ff release/2.5.0

# Vytvoření tagu vydání
git tag -a v2.5.0 -m "Release 2.5.0 - Payment integration"

# Odeslání main a tagu na server
git push origin main --tags

Přepínač --no-ff (no fast-forward) zaručuje vytvoření merge commitu, i když by sloučení mohlo být provedeno jednoduchým posunem ukazatele. To zachovává informaci o tom, že změny pocházejí z release větve, což zjednodušuje analýzu historie.

Práce s hotfix přes main

Pokud je v produkci objevena kritická chyba, proces se liší od běžného vydání. Hotfix se vytváří z main a po opravě se slučuje jak do main, tak do develop.

Pokud je v produkci objevena kritická chyba, proces se liší od běžného vydání. Hotfix se vytváří z main a po opravě se slučuje jak do main, tak do develop.

# Vytvoření hotfix větve z main
git checkout main
git checkout -b hotfix/2.5.1-crash-fix

# Oprava a commit
git add src/fix/
git commit -m "Fix crash on login screen"

# Sloučení hotfix zpět do main
git checkout main
git merge --no-ff hotfix/2.5.1-crash-fix
git tag -a v2.5.1 -m "Hotfix 2.5.1"
git push origin main --tags

# Sloučení hotfix také do develop
git checkout develop
git merge --no-ff hotfix/2.5.1-crash-fix
git push origin develop

# Odstranění hotfix větve
git branch -d hotfix/2.5.1-crash-fix