TIP: Přetáhni ikonu na hlavní panel pro připnutí webu
Přestože je Git tak skvělým pomocníkem a hezky napsaným kusem programu, všechno má i své mouchy. Git není výjimkou.
Je tu pár problémů, které vymetu zpod koberce. Některé mohou být vyřešeny pomocí různých skriptů a kliček, některé vyžadují přeorganizování či předefinování projektu a kvůli některým zbývajícím otravnostem si bude muset jeden prostě počkat. Nebo lépe sám pomoci!
Slabosti SHA1
Jak čas postupuje, kryptologové odhalují více a více slabostí SHA1. Již nyní je pro dobře financované společnosti proveditelné najít kolize. Během pár let bude moci snad i normální osobní počítač mít tolik výpočetní síly, aby potichu poškodil Gití repozitář.
Doufejme, že Git přejde na lepší hashovací funkci předtím, než výzkum zničí SHA1.
Microsoft Windows
Provozovat Git na Microsoft Windows může být těžkopádné:
- Cygwin, linuxové prostředí pro Windows obsahuje Windowsí port Gitu.
- MSys Git je alternativa požadující minimální nároky na běhovou podporu, i když některé příkazy potřebují ještě propracovat.
Nesouvisející soubory
Pokud je váš projekt velký a obsahuje mnoho nesouvisejících souborů, které jsou neustále měněny, Git může být mnohem více znevýhodněn než ostatní systémy, protože soubory nejsou sledovány jednotlivě. Git sleduje změny na celém projektu, což je povětšinou prospěšné.
Řešením je rozdělit projekt na části, kde každá sestává ze
souvisejících souborů. Jestliže chcete, aby bylo vše stále v jednom
repozitáři, podívejte se na git submodule.
Kdo co mění?
Některé verzovací systémy vás nutí, abyste výslovně označili nějakou cestou soubor předtím, než ho začnete upravovat. Přestože je toto zvláště otravné, protože to vyžaduje komunikaci s centrálním serverem, má to dvě výhody:
- Diffy jsou rychlé, protože musí být prověřeny jenom označené soubory .
- Člověk může objevit, kdo další pracuje na souboru, tím, že se zeptá centrálního serveru, kdo ho označil pro úpravu.
S odpovídajícím skriptováním můžete docílit toho samého s Gitem. Vyžaduje to spolupráci od programátora, který by měl spustit příslušný skript, když začne upravovat soubor.
Historie souboru
Jelikož Git zaznamenává změny celého projektu, vybudovat historii jediného souboru vyžaduje více práce než ve verzovacích systémech, které sledují soubory individuálně.
Zpomalení je to malé a vyplatí se v porovnání s tím, že ostatní
operace jsou úžasně rychlé. Například git checkout je
rychlejší než cp -a a změny celého projektu (delty) jsou na
zkomprimování lepší než balík změn souborů.
Počáteční klonování
Když má projekt bohatou historii, vytvořit klon je mnohem náročnější, než stáhnout kód poslední revize v jiných verzovacích systémech.
Počáteční „náklady“ jsou ale dobré „zaplacení“
v dlouhodobější perspektivě, protože většina budoucích operací bude
rychlá a offline. Nicméně v některých situacích může být lepší
vytvořit jen mělký klon pomocí volby --depth. Výstupní klon
má omezenou funkčnost, ale je to mnohem rychlejší.
Nestálé projekty
Git byl napsán, aby byl rychlý vzhledem k velikosti změn. Lidé dělají malé změny z verze na verzi. Jednořádková oprava chyby sem, nová funkce tam, zlepšení komentářů a tak podobně. Ale když jsou vaše soubory radikálně jiné v navazujících revizích, pak každým commitem historie nutně roste s velikostí celého projektu.
Není zde nic, co by s tím mohl jakýkoli verzovací systém udělat, ale normální uživatelé Gitu budou trpět více, poněvadž se normálně kopíruje celá historie.
Měli byste přezkoumat důvody tak velkých změn. Možná zauvažovat o změně formátu souborů. Málo významné změny by měly pouze způsobit malé úpravy nejvíce na pár souborech.
Možná že hledáte databázi nebo zálohovací/archivační řešení, ne verzovací systém. Například verzování může být nevhodné pro správu opakovaně pořizovaných fotek z webkamery.
Pokud musí být soubory neustále měněny a opravdu musí být verzované, je zde možnost používat Git centralizovaně. Jeden pak vytváří mělké klony, které si stahují pouze kousek historie projektu. Samozřejmě že mnoho Gitích nástrojů pak nebude přístupno a opravy musí být posílány jako patche. Ale toto je pravděpodobně v pořádku, protože není jasné, proč by někdo chtěl historii takto nestálých souborů.
Dalším příkladem je projekt závisející na firmwaru, který má podobu velkého binárního souboru. Historie firmwaru uživatele nezajímá a aktualizace se špatně komprimují, tudíž revize by zbytečně vystřelily velikost repozitáře kamsi k výšinám.
V tomto případě by měl být zdrojový kód uložen v Gitím repozitáři a binární soubor někde odděleně. K ulehčení života byste mohli distribuovat skript, který použije Git k naklonování kódu a rsync nebo Gití mělký klon pro firmware.
Globální počítadlo
Některé centralizované systémy obhospodařují celé kladné číslo, které se zvětšuje, když je přijat nový commit. Git ukazuje na změny podle jejich hashe, což je v mnoha případech lepší.
Ale někteří lidé mají rádi, když tam někde to číslo je. Naštěstí je jednoduché si napsat skript, který s každou aktualizací v centrálním repozitáři zvětší číslo, pravděpodobně tag, a přidá ho k hashi posledního commitu.
Každý klon může mít takové počítadlo, ale to bude pravděpodobně zbytečné, protože počítadlo centrálního repozitáře je rozhodující pro všechny.
Prázdné podadresáře
Prázdné podadresáře nemohou být sledovány. Vyřešit to můžete vytvořením „hloupých“ souborů.
Spíše než design je momentální implementace to, co bychom měli vinit za tento nedostatek. Jak vznikne na Git větší tlak, více uživatelů začne volat po této vlastnosti, a tak bude implementována.
Počáteční commit
Stereotypní počítačoví vědci počítají od 0 radši než od 1. Bohužel, vzhledem ke commitům, Git se nedrží této konvence. Mnoho příkazů je nepřátelských před počátečním commitem. Navíc s pár mezními případy musí být zacházeno speciálně, jako například rebase s rozdílnými počátečními commity.
Gitu by prospělo definovat nulový commit: hned, jak je repozitář vytvořen, by se HEAD nastavila na řetězec obsahující 20 nulových bytů. Tento speciální commit by zastupoval prázdný strom bez jakéhokoli rodiče, který by předcházel všechny Gití repozitáře.
Potom by spuštění git log místo skončení s fatální
chybou informovalo o tom, že ještě nebyly provedeny žádné
commity. Podobně pro ostatní nástroje.
Každý počáteční commit je bezpodmínečně potomek tohoto
nultého commitu. Například rebase nesouvisející větve by
způsobilo její naroubování na cíl. Nyní jsou všechny commity
krom počátečního aplikovány, což vyústí v slučovací konflikt. Jedním
řešením je použít git checkout následovaný git commit
-C na počáteční commit a potom udělat rebase
ostatního.
Bohužel jsou tu i horší případy. Když je slučováno několik větví s rozdílnými počátečními commity, výsledek rebase vyžaduje velké ruční zásahy.
Tento článek je překladem osmé a poslední kapitoly – Git Shortcomings – z GitMagic od Bena Lynna.
