TakéDistributed version control system, DVCS, verzovací systémPokročilý
Definice
Git je distribuovaný systém pro správu verzí zdrojového kódu, který ukládá historii změn jako propojené commity a umožňuje práci s větvemi bez stálého připojení k serveru. Vývojář díky němu porovná verze, vrátí chyby, spojí práci více lidí a bezpečně publikuje změny do sdíleného repozitáře.
Proč Git pracuje lokálně
Git ukládá úplnou historii projektu do lokálního repozitáře. Vývojář proto může vytvářet commity, procházet starší verze, hledat autora změny nebo zakládat větve i bez dostupného serveru. Vzdálený repozitář slouží hlavně ke sdílení práce s ostatními, ne jako jediné místo, kde existuje historie.
Distribuovaný model mění běžný rytmus vývoje. Lokální operace jsou rychlé, protože Git obvykle nemusí čekat na síť. Tým pak synchronizuje jen vybrané změny příkazy jako push, pull nebo fetch. Server může být GitHub, GitLab, Bitbucket, vlastní stroj přes SSH nebo i obyčejný adresář.
Commit jako otisk stavu projektu
Commit v Gitu není jen rozdíl v jednom souboru. Commit popisuje konkrétní stav sledovaných souborů, odkazuje na předchozí commit a má identifikátor odvozený z obsahu. Díky tomu Git umí poznat, zda se historie změnila, a dokáže většinu operací provést jako práci s propojeným grafem.
Praktický význam commitu je auditní stopa. Dobře pojmenovaný commit říká, proč změna vznikla, ne pouze co se změnilo. Příkaz git status ukáže rozpracované soubory, git add vybere změny do příštího commitu a git commit je zapíše do historie lokálního repozitáře.
Větve bez kopírování adresářů
Větev v Gitu je lehký ukazatel na commit, ne samostatná kopie celého projektu. Vývojář tak může založit větev pro opravu chyby, experiment nebo novou funkci a později ji spojit s hlavní vývojovou linií. Přepnutí větve mění pracovní adresář podle vybraného bodu historie.
Spojování větví probíhá nejčastěji příkazem merge nebo rebase. Merge zachová informaci, že se potkaly dvě linie vývoje. Rebase přepíše pořadí lokálních commitů tak, aby vypadaly jako navázané na novější základ. Volba závisí na týmových pravidlech a na tom, zda už byla historie sdílená.
Kde Git začne bolet
Git je nejsilnější u textových souborů: zdrojového kódu, konfigurace, dokumentace nebo testů. Velké binární soubory, generované výstupy a časté přepisování stejného souboru více lidmi vytvářejí větší repozitář a horší slučování. Pro grafiku, video nebo datové sady se často přidává Git LFS nebo jiné úložiště artefaktů.
Spolehlivá práce s Gitem vyžaduje disciplínu. Repo nemá obsahovat hesla, privátní klíče ani zbytečné build výstupy. Soubor .gitignore pomáhá vyloučit lokální a generované soubory. Týmová dohoda o větvích, kontrole kódu a zprávách commitů bývá důležitější než samotná znalost příkazů.
Příklady z praxe
Oprava chyby v samostatné větvi
Vývojář najde chybu v přesměrování po přihlášení a nechce riskovat rozbití hlavní větve. Založí samostatnou větev, uloží opravu do commitu a odešle větev na server. Tým pak může změnu zkontrolovat a sloučit až po review.
git switch -c fix-login # úprava souboru auth.js git add auth.js git commit -m "Fix login redirect" git push origin fix-loginRuční vyřešení konfliktu
Dva vývojáři upraví stejnou část konfiguračního souboru a Git nedokáže bezpečně rozhodnout, která verze má vyhrát. Při stažení změn vznikne konflikt. Vývojář soubor otevře, vybere správnou kombinaci úprav a výsledek zapíše novým commitem.
git pull # Git oznámí konflikt v src/settings.js git status # vývojář soubor ručně upraví git add src/settings.js git commit
Časté omyly
- MýtusGit je totéž co GitHub.
- Ve skutečnostiGit je verzovací systém, který může běžet lokálně i na vlastním serveru. GitHub je jedna z platforem, které repozitáře Gitu hostují a přidávají kolem nich týmové funkce.
- MýtusKdyž soubor smažu a commitnu, v Gitu je navždy pryč.
- Ve skutečnostiGit uchovává historii commitů, takže starší verze souboru lze najít, pokud nebyla historie záměrně přepsána a odstraněna. Smazání v aktuální větvi neznamená okamžité zmizení ze všech starších commitů.
- MýtusPull vždy bezpečně stáhne změny a nic nerozbije.
- Ve skutečnostiGit pull může vytvořit merge commit, spustit rebase podle nastavení nebo zastavit na konfliktu. Bez kontroly stavu pracovní kopie může stažení změn zkomplikovat rozpracovanou práci.
Časté dotazy
- Musí Git vždy používat GitHub?
- GitHub není nutnou součástí Gitu. Git je nástroj a datový model pro verzování, zatímco GitHub je hostovaná služba nad repozitáři Gitu. Projekt může používat Git bez internetu jen na jednom počítači, na vlastním serveru přes SSH nebo v jiné službě, například GitLab. GitHub přidává pull requesty, správu oprávnění, issue tracking, CI a webové rozhraní.
- Co se v Gitu stane při commitu?
- Commit v Gitu uloží vybraný stav sledovaných souborů do historie lokálního repozitáře. Commit obsahuje identifikátor, autora, čas, zprávu a odkaz na předchozí commit nebo commity. Samotný commit se automaticky neposílá ostatním lidem. Sdílení nastane až při odeslání do vzdáleného repozitáře, typicky příkazem git push.
- Proč Git hlásí merge conflict?
- Merge conflict v Gitu vznikne, když dvě větve změní stejnou oblast souboru nebo když jedna větev soubor smaže a druhá ho upraví. Git v takové situaci nechce hádat, která varianta je správná. Vývojář musí konfliktní soubor ručně upravit, zkontrolovat výsledek, označit soubor jako vyřešený a vytvořit commit se sloučením.
- Kdy Git nestačí pro velké soubory?
- Git není ideální jako hlavní úložiště pro velké binární soubory, videa, datové sady nebo generované artefakty. Binární obsah se špatně porovnává, slučuje a při častých změnách rychle zvětšuje historii repozitáře. Týmy v takových případech používají Git LFS, registry balíčků, objektová úložiště nebo specializovanou správu artefaktů.
Zdroje
- git Documentation(otevře se v novém okně)
- Git Reference(otevře se v novém okně)
- Pro Git(otevře se v novém okně)
- Git - About(otevře se v novém okně)
Související pojmy
