Git po dvaceti letech: změny přijdou pomalu

GitHub ve zprávě Octoverse 2025 uvádí přes 180 milionů vývojářů a 630 milionů repozitářů. Ve veřejných projektech eviduje 11,5 miliardy CPU minut ve službě GitHub Actions za rok 2025. Čísla pocházejí od firmy, která má na velikosti platformy vlastní zájem, přesto dobře vystihují rozsah: přes Git se dnes řeší spolupráce, automatické testy, bezpečnostní kontroly i vydávání softwaru.

Původní cíl byl užší. Git vznikl v roce 2005 po konci bezplatného použití BitKeeperu pro vývoj linuxového jádra. Krátká historie Gitu jmenuje rychlost, jednoduchý návrh, podporu nelineárního vývoje, distribuovanost a práci s velkými projekty. Linus Torvalds v rozhovoru k výročí Gitu na GitHub Blogu popsal motivaci přímo: potřeboval nástroj pro sebe a pro vývoj linuxového jádra.

Tomu odpovídá i dnešní podoba. Objektový model je malý, příkazy nad ním už ne. Git kombinuje nízkoúrovňové mechanismy s uživatelským rozhraním, které za dvě desetiletí narostlo. Zkušený správce repozitáře z toho těží. Člověk, který chce jen vrátit špatný commit, přesunout změnu jinam nebo opravit větev po rebase, se často musí naučit část interního modelu.

Hash v Gitu určuje identitu objektu

Commit, strom i blob mají v Gitu identitu odvozenou od obsahu. Historie tvoří acyklický graf commitů, každý commit ukazuje na rodiče a na strom souborů. Kapitola Git Internals: Git Objects dobře ukazuje, jak malé jádro celého modelu ve skutečnosti je.

Takový návrh pomáhá integritě dat, levnému větvení a práci bez centrálního serveru. Git umí ověřit historii lokálně, rychle vytvořit větev a po síti přenášet jen chybějící objekty. Pro dlouho žijící textový projekt je to pořád dobrá volba.

Stejný návrh ale komplikuje změny. Přechod od SHA-1 k SHA-256 není prostá výměna algoritmu. Hash v Gitu určuje identitu objektu. Dokument hash-function-transition proto řeší nový formát repozitáře, mapování mezi SHA-1 a SHA-256, přenos přes síť a kompatibilitu se staršími klienty. Starší Git SHA-256 repozitář nepřečte.

Uživatelé narážejí na stavy

Část potíží s Gitem vzniká u běžných operací. Git má pracovní strom, index a historii. Index, často označovaný jako staging area, je podle dokumentace git add místo, kam se změny připraví pro další commit. Teprve git commit z nich vytvoří záznam v historii.

Index se hodí při pečlivém skládání commitů. Do commitu lze vzít jen část změn a zbytek nechat stranou. Pro vývojáře z jednoduššího modelu „ulož aktuální stav“ je to další skrytý stav. Soubor může být změněný, částečně připravený, sledovaný, nesledovaný, ignorovaný nebo odstraněný jen v indexu. Git tyto rozdíly potřebuje, uživatel je musí znát.

Podobný problém měl dlouho příkaz git checkout. Sloužil k přepínání větví, obnově souborů i přechodu na konkrétní commit. Git 2.23 přidal git switch a git restore, aby tyto úlohy oddělil. Přehled Highlights from Git 2.51 uvádí, že po šesti letech už nejde o experimentální příkazy. Starý git checkout ale zůstává v dokumentaci, návodech, skriptech a paměti uživatelů.

Detached HEAD ukazuje stejný rozdíl mezi interním modelem Gitu a tím, co uživatel čeká. V interním modelu jde o normální stav: HEAD ukazuje přímo na commit, ne na větev. Vývojář v něm může vytvořit commit, který později nebude patřit žádné větvi. Git varuje, jenže koncept nezmizí. Bez něj by nešlo historii pohodlně procházet a testovat.

Podobný obrázek dávají data ze studie Do Developers Really Know How to Use Git Commands?. Autoři analyzovali 80 370 příspěvků ze Stack Overflow a dotazovali 92 vývojářů. Mezi častými a prakticky náročnými tématy vyčnívaly záchranné operace: git revert, git reflog,git stash a git reset. Mnoho dotazů se tedy netýká teorie verzování, ale návratu z chybného stavu nebo obnovy práce.

Nové formáty míří na velké repozitáře

V původním prostředí je Git pořád rychlý. Projekt na svém webu uvádí, že historie linuxového jádra s více než milionem commitů zabírá jen několik gigabajtů. U textového projektu s dlouhou historií je to pořád dobrý výsledek. Potíže začínají tam, kde přibývá referencí, souborů nebo binárních dat.

Formát reftable řeší hlavně velké množství referencí. Běžné ukládání přes soubory a packed-refs je jednoduché a čitelné. U velkého počtu větví a tagů se ale prodražuje zápis, přepisování velkých souborů i spolehlivé provedení změny bez mezistavu. Dokumentace reftable popisuje nový formát jako kompaktní tabulku pro reference a záznamy reflogů.

Dokumentace BreakingChanges počítá s tím, že Git 3.0 použije u nově vytvářených repozitářů SHA-256 jako výchozí hash a reftable jako výchozí formát referencí. Zmiňuje také větev main jako výchozí název a povinný Rust při sestavení. Datum vydání Gitu 3.0 zatím stanoveno není. Projekt také neplánuje odstranit podporu SHA-1.

Velké repozitáře mají i další potíže. Dokumentace partial clone popisuje klony, které mohou trvat hodiny až dny a spotřebovat přes 100 GiB místa. Proto existují partial clone, sparse checkout, sparse index, FSMonitor, git maintenance a Scalar. Git už nemůže vždy počítat s tím, že každý uživatel stáhne celou historii a celý pracovní strom.

Binární soubory jsou zvláštní případ. Git dobře komprimuje podobné textové verze. U médií, datasetů, sestavených artefaktů nebo už komprimovaných binárních dat dává horší výsledky. Git LFS používá ukazatele na velké soubory a externí úložiště, git-annex spravuje obsah mimo běžný gitový objektový model. U médií, datasetů nebo sestavených artefaktů se proto vyplatí oddělit zdrojový kód od dat, která Git neumí ukládat úsporně.

Nahradit Git znamená měnit procesy

Mercurial býval častou volbou pro uživatele, kterým Git připadal zbytečně nepřímý. Fossil spojuje správu verzí s webovým rozhraním, wiki a sledováním chyb. Pijul a Darcs pracují s jiným pojetím změn. Jujutsu zůstává kompatibilní s Gitem, ale přidává záznam operací a jednodušší návrat změn.

Lepší model verzování by migraci sám nevyřešil. Git je napojený na GitHub, GitLab, Giteu a další hostingové služby pro správu repozitářů. Kolem nich jsou pull requesty, chráněné větve, automatické kontroly, bezpečnostní skeny, vydávací pipeline, interní pravidla firem a náborové zvyklosti. Přechod na jiný systém znamená převést historii a změnit platformu, automatizaci, dokumentaci, oprávnění i návyky týmů.

Grafická rozhraní a integrace v IDE pomáhají hlavně se syntaxí. Neodstraňují index, reference, reflog, detached HEAD ani přepisovanou identitu commitů. Když uživatel nerozumí modelu, hezčí dialog mu často jen skryje příkaz, který by jinak napsal v terminálu.

Jedna použitelná cesta už existuje: rozdělení checkout na switch a restore. Podobný směr má i experimentální příkaz git history v Gitu 2.54, který zatím nabízí operace reword a split: přepsání zprávy staršího commitu a rozdělení commitu na dva. Git tak může přidávat užší a bezpečnější operace pro běžnou práci, aniž rozbije staré skripty.

Git 3.0 nebude nový začátek

Pro běžné vývojáře bude Git 3.0 spíš změna výchozích formátů než nový způsob práce. SHA-256 se bude prosazovat pomalu, protože zasahuje identitu objektů a kompatibilitu. Reftable dává největší smysl na serverech a v repozitářích s velkým počtem referencí. Velké objekty zůstanou rozdělené mezi LFS, git-annex a nové mechanismy přímo v Gitu.

Správci větších repozitářů by proto neměli čekat na jednu verzi, která odstraní současné slabiny. Pomáhá spíš omezený a srozumitelný způsob práce: jasná pravidla pro merge a rebase, opatrnost se submoduly, znalost reflogu, oddělení binárních dat od zdrojového kódu a zapnuté optimalizace pro velké repozitáře.

Po dvaceti letech se z Gitu nestane jednoduchý nástroj pro každého. Vývojáři ho budou měnit za běhu. Kdo s ním pracuje denně, tomu se pořád vyplatí jedna stará poučka: neučit se jen příkazy, ale stavy. Pak se většina chyb opravuje rychleji než náhodným hledáním v adresáři  .git.