Jak skutečně funguje GIT?

GIT je v současné době asi nejpoužívanější nástroj pro správu verzí. A přes to, že drtivá většina nejen vývojářů GIT používá, nebo se s ním alespoň setkala, jen malé procento lidí skutečně ví, co GIT skutečně dělá a jak to dělá. Přitom porozumění pár základním principům týkajících se toho, jak jsou v GITu uložena a verzována data, může nejen dramaticky zvýšit efektivitu práce s tímto nástrojem, ale i předejít frustraci a nejistotě, kterou spousta vývojářů denně při práci s GITem zažívá.

Jak GIT ukládá data?

Prvním krokem k porozumění, jak GIT funguje, je pochopení toho, jak jsou v GITu uložena data. Většina uživatelů tohoto nástroje jistě ví, že v adresáři s repositářem se nachází podadresář .git. A je to právě tento adresář, kde se děje všechna ta magie, kterou GIT provádí s našimi  projekty. Pojďme tedy nakouknout pod pokličku GITu a krok za krokem ukázat, co přesně se děje od chvíle, kdy vytvoříme nový repositář příkazem git init, až do chvíle, kdy vytvoříme první commit.

Prvním krokem, který musíme podniknout je inicializace nového repositáře. K tomuto účelu nám GIT poskytuje příkaz init, který nedělá nic jiného, než že vytvoří ve vybraném adresáři podadresář .git. V tuto chvíli se v něm nenachází nic zajímavého, tak s tím pojďme něco udělat a přidat první soubor do našeho projektu. Vytvoříme tedy v kořenovém adresáři projektu soubor readme.txt a vložíme do něj nějaké užitečné informace. Pokud se v tuto chvíli podíváme do adresáře .git, tak pořád neuvidíme žádné změny, avšak příkaz git status nám říká, že v adresáři projektu objevil nový soubor. Příkazem git add readme.txt tento sobor přidáme do tzv. stage area a git status nám nyní říká, že změny provedené v tomto souboru budou obsaženy v dalším commitu.

Co se ale stalo v adresáři .git? Na obrázku vidíme, že se zde objevily dva nové soubory – .git/index a .git/objects/65/83cd…. Souborem index se v tomto článku nebudeme zabývat, pro jednoduchost stačí říct, že se jedná o soubor, ve kterém GIT zaznamenává změny ve stage area a vytváří pomocí něj commity. Druhý zmíněný soubor vznikl v adresáři objects a pokud se pokusíme zobrazit jeho obsah, tak se se zlou potážeme. Git totiž ukládá objekty následujícím způsobem:

  1. Vytvoří hash obsahu souboru pomocí SHA-1
  2. Vytvoří soubor v adresáři objects, který je pojmenován dříve vypočteným SHA-1 otiskem a jeho obsah je komprimovaný obsah daného souboru.

První dva znaky hashe jsou použity pro název podadresáře adresáře objects. Toto opatření je zde zejména kvůli ulehčení práce souborovému systému, který tak nemusí pracovat s příliš mnoha soubory v jednom adresáři. Pokud bychom přece jen chtěli nahlédnout do obsahu tohoto komprimovaného souboru, můžeme použít příkaz git cat-file -p HASH.

Je důležité zdůraznit, že pokud nyní provedeme změny v souboru readme.txt a opět tyto změny přidáme do stage area pomocí příkazu add, tak vznikne nový soubor s kompletně novým obsahem. Toto chování je nutné, právě z toho důvodu, že GIT pojmenovává objekty otiskem jejich obsahu a je to právě toto chování, které nám dále pomůže pochopit to, jak je vytvořen commit a potažmo celý graf historie commitů v repositář.

Typy objektů v GITu

GIT ukládá data do adresáře .git/objects a lze zde nalézt tři základní typy objektů – blob, tree a commit. U objektů typu tree a blob lze vypozorovat analogii se souborovým systémem, protože tree objekty slouží k reprezentaci adresářů a blob objekty pak ukládají samotná data z jednotlivých souborů. Celý adresář repositáře je tak reprezentován jedním tree objektem, který obsahuje reference buď na další podadresáře (tree), nebo verzované soubory (blob).

Napsáním příkazu commit vznikne nový soubor typu commit, který kromě samotné reference na kořenový tree objekt obsahuje také reference na předchozí commit (parent), informace o autorovi a další.

Je důležité si uvědomit, že jakákoliv změna v libovolném verzovaném souboru vede ke změně nejen otisku daného blobu, ale i všech tree objektů směrem ke kořenovému adresáři a tím pádem i otisku samotného commitu.

Závěr

Cílem tohoto článku bylo v první řadě seznámit čtenáře alespoň rámcově s obsahem školení o verzovacím systému GIT, které nedávno proběhlo u nás v BCV solutions. Článek si rozhodně neklade za úkol detailně popsat implementaci GITu, ale spíše probudit ve čtenáři zájem o toto téma, s čímž ruku v ruce jde i lepší pochopení toho, jak GIT funguje.

Pokud Vás článek zaujal, nebo pokud máte jakýkoliv dotaz ohledně tohoto tématu, neváhejte se obrátit na info@bcvsolutions.eu.