Pushnout — co to je, jak funguje git push a kdy je potřeba

Co je push v Gitu

Git push je příkaz, který přenáší commity z lokálního repozitáře do vzdáleného. Na rozdíl od commitu, který ukládá změny pouze na lokálním počítači vývojáře, push tyto změny publikuje pro celý tým. Push je povinný krok před vytvořením Pull Requestu a nasazením.

Architektura Gitu předpokládá, že každý vývojář pracuje ve svém vlastním lokálním repozitáři. Commity se vytvářejí lokálně a hromadí se, dokud se vývojář nerozhodne je pushnout. To dává svobodu: můžete dělat mnoho lokálních commitů, experimentovat a přepisovat historii bez ovlivnění kolegů.

# Push do origin remote, main větve
git push origin main

# Push aktuální větve do remote s upstream
git push -u origin feature/new-dashboard

# Push všech větví s odpovídajícími názvy
git push --all origin

# Force push s lease (bezpečný force push)
git push --force-with-lease

Po pushi vzdálený repozitář aktualizuje refs (reference na větve) tak, aby ukazovaly na nové commity. Ostatní vývojáři mohou tyto změny získat pomocí git pull nebo git fetch. Právě tato výměna commitů tvoří základ kolaborativního vývoje.

Jak funguje git push

Příkaz git push porovnává lokální a vzdálené větve a přenáší pouze chybějící commity. Git neposílá všechny soubory znovu — přenáší pouze deltu, což dělá push rychlým i u velkých repozitářů. Git protokol používá smart transfer, který minimalizuje objem přenášených dat.

Pokud vzdálená větev obsahuje commity, které lokálně neexistují, push bude odmítnut. Toto je ochranný mechanismus zabraňující ztrátě změn. V takové situaci by měl vývojář nejprve provést git pull, sloučit změny a teprve poté pushnout znovu. Alternativou je force push, který přepíše vzdálenou větev, ale musí být používán opatrně.

Porozumění vzdáleným repozitářům je klíčem ke správnému pushování. Obvykle se používá origin — výchozí název vzdáleného repozitáře. Příkaz git remote -v zobrazuje seznam vzdálených repozitářů a jejich URL. Lze přidat několik remote (např. origin pro hlavní repozitář a upstream pro fork).

Kdy pushnout změny

Základní pravidlo: pushovat by se mělo po každé logicky dokončené fázi práce. Pokud vývojář dokončil úkol nebo jeho část — je čas pushnout. Nicméně pushování nedokončené práce, která rozbíjí build, se nedoporučuje. Nerozbitý build je minimální požadavek pro push do jakékoli větve.

V týmovém vývoji je přijat následující rytmus: ráno — git pull pro získání změn kolegů, během dne — několik commitů a jeden nebo dva pushy, večer — finální push všech dokončených úkolů. Čím častěji vývojář pushuje, tím menší je riziko konfliktů při slučování větví a tím transparentnější je postup práce.

• Po dokončení úkolu — commitnout a pushnout konečné řešení do feature větve
• Před odchodem — pushnout nedokončenou práci do feature větve (ne do main!)
• Před vytvořením PR — ujistit se, že všechny commity jsou pushnuty a dostupné pro review
• Po rebase — pushnout s --force-with-lease do své feature větve

Pravidla bezpečného pushování

Bezpečný push je soubor pravidel zabraňujících ztrátě dat a konfliktům v týmu. První a nejdůležitější pravidlo: nikdy nepushujte přímo do main nebo master větve, pokud v projektu není nakonfigurováno přímé nasazení. V moderních týmech je ochrana main větve konfigurována na úrovni GitHub branch protection.

Druhé pravidlo: před pushem se synchronizujte se vzdálenou větví. Proveďte git pull --rebase, abyste se vyhnuli merge commitu při slučování. To zjednodušuje historii a činí ji lineární. Pokud je push odmítnut — nepoužívejte holý force push, ale nejprve zjistěte, jaké commity se objevily ve vzdálené větvi.

Třetí pravidlo: nakonfigurujte pre-push hooky, které automaticky spouštějí testy a linter před odesláním. Pokud testy selžou — push je zablokován. Takové hooky se konfigurují přes Husky nebo Git hooks (soubor pre-push v .git/hooks).

Čtvrté pravidlo: nepushujte velké binární soubory. Git není určen k ukládání binárních artefaktů — nafukují repozitář a zpomalují operace. Pro velké soubory se používá Git LFS (Large File Storage). Pokud byl binární soubor již pushnut a dostal se do historie, musí být odstraněn pomocí git filter-branch.

Co dělat, když push neprojde

Nejčastější příčinou neúspěšného pushování — vzdálená větev obsahuje commity, které lokálně neexistují. To se stane, když jiný vývojář pushnul své změny do stejné větve. Řešení: proveďte git pull, vyřešte případné konflikty a zopakujte push.

# Push odmítnut — nejprve fetch a rebase
git fetch origin
git rebase origin/main
# Vyřešit konflikty, poté:
git push --force-with-lease

# Nebo jednoduše sloučit vzdálené změny
git pull origin main
git push

Druhá příčina — nedostatek práv k zápisu do větve. Pokud je main větev chráněna pravidlem branch protection, přímé pushy jsou zakázány. Řešení: pushujte do feature větve a vytvořte Pull Request. Nastavení ochrany jsou obvykle spravována přes GitHub settings nebo GitLab protected branches.

Třetí příčina — problémy s autentizací. Zastaralé přihlašovací údaje, přechod na SSH nebo změna personal access tokenu. Řešení: zkontrolujte remote URL (git remote -v) a aktualizujte přihlašovací údaje. Od roku 2021 GitHub zrušil autentizaci heslem pro HTTPS — používá se osobní token nebo SSH klíč.