Repository v Gitu: co to je, jaké typy existují a jak fungují

Co je repozitář v Gitu

Git repozitář — je datová struktura, ve které systém pro správu verzí ukládá metadata a objekty popisující historii změn souborů projektu. Když vývojář inicializuje repozitář příkazem git init, Git vytvoří skrytou složku .git v kořenu projektu.

Uvnitř této složky se nacházejí všechny objekty, reference a konfigurační soubory potřebné pro fungování systému. Repozitář není vázán na konkrétní umístění — vývojář jej může vytvořit lokálně a poté připojit ke vzdálenému serveru.

Git používá model distribuovaného repozitáře: každý účastník projektu má úplnou kopii historie na svém počítači. To znamená, že většina operací — commit, prohlížení historie, vytváření větví — se provádí lokálně bez přístupu k serveru.

Podle dokumentace Gitu činí distribuovaná architektura systém odolným vůči výpadkům: pokud server selže, jakýkoli lokální repozitář se může stát zdrojem pro obnovení úplné historie projektu.

Lokální a vzdálený repozitář

Lokální repozitář — je kopie projektu na počítači vývojáře. Obsahuje celou historii commitů, větví a tagů a umožňuje provádět operace commit, branch, merge a rebase bez připojení k síti.

Vzdálený repozitář je hostován na serveru a slouží jako synchronizační bod pro všechny členy týmu. Vývojáři odesílají své změny příkazem git push a stahují změny ostatních příkazem git pull.

Spojení mezi lokálním a vzdáleným repozitářem se nastavuje prostřednictvím remote origin — URL serveru uloženého v konfiguraci Gitu. Jeden lokální repozitář může být připojen k několika vzdáleným repozitářům, což je užitečné při práci s forky.

Hlavní výhodou tohoto modelu je, že vývojář může pracovat na kódu offline a synchronizovat změny pouze tehdy, když je připraven odeslat výsledek.

Rozdíly mezi lokálním a vzdáleným repozitářem

Jak Git ukládá data v repozitáři

Model ukládání Gitu se zásadně liší od ostatních systémů pro správu verzí. Místo ukládání seznamu změn (delt) mezi verzemi ukládá Git úplné snímky všech souborů projektu v okamžiku každého commitu.

Každý objekt v repozitáři je identifikován unikátním SHA-1 hashem o délce 40 znaků. Pokud se obsah souboru mezi commity nezměnil, Git nevytváří nový objekt, ale znovu používá existující — to šetří místo.

Git používá čtyři typy objektů: blob (obsah souboru), tree (struktura adresáře), commit (snímek s metadaty) a tag (pojmenovaná reference na commit). Všechny objekty jsou uloženy ve složce .git/objects.

Podle Git Internals objektový model Gitu zajišťuje integritu dat: jakákoli změna obsahu souboru vede k novému hashi, což znemožňuje nenápadnou úpravu historie.

Struktura složky .git

Složka .git — je srdcem repozitáře. Bez ní Git nemůže sledovat změny a běžný adresář zůstává pouze sbírkou souborů. Porozumění struktuře této složky pomáhá diagnostikovat problémy s repozitářem.

• objects/ — všechny objekty repozitáře: bloby, stromy, commity, tagy. Uloženy v komprimované podobě.
• refs/ — reference na commity: heads (větve), tags (značky), remotes (vzdálené větve).
• HEAD — soubor ukazující na aktuálně aktivní větev nebo commit.
• config — nastavení repozitáře: vzdálené URL, uživatelské jméno, e-mail a další parametry.
• index — staging area (index), kde Git ukládá informace o souborech připravených k commitu.
• logs/ — protokoly o aktualizaci referencí (reflog), které ukládají historii pohybu HEAD a větví.

Soubor HEAD si zaslouží zvláštní pozornost. V normálním stavu obsahuje symbolickou referenci na větev, například ref: refs/heads/main. Ve stavu detached HEAD ukazuje přímo na commit — to znamená, že nové commity nebudou připojeny k žádné větvi.

Základní operace s repozitářem

Práce s Git repozitářem zahrnuje sadu základních operací, které vývojář provádí denně. Každá operace mění stav repozitáře, přidává nové objekty nebo přesouvá reference.

• git init — vytvoří nový prázdný repozitář v aktuálním adresáři. Git vytvoří složku .git s počáteční strukturou.
• git clone — zkopíruje existující vzdálený repozitář na lokální počítač spolu s celou historií commitů.
• git add — přidá změny souborů do staging area (indexu) a připraví je k commitu.
• git commit — vytvoří snímek projektu na základě dat z indexu a uloží jej jako nový objekt commitu.
• git push — odešle nové commity z lokálního repozitáře do vzdáleného a aktualizuje větve na serveru.
• git pull — stáhne nové commity ze vzdáleného repozitáře a sloučí je s aktuální lokální větví.

Operace push a pull — jsou jediné, které vyžadují připojení ke vzdálenému serveru. Všechny ostatní operace se provádějí zcela lokálně, což zajišťuje vysokou rychlost práce i při velkém objemu historie.

Životní cyklus souboru v repozitáři

Každý soubor v repozitáři prochází čtyřmi stavy: untracked (nesledovaný), modified (změněný), staged (připravený) a committed (zkomitovaný). Git sleduje pouze soubory, které byly explicitně přidány prostřednictvím git add nebo se již nacházejí v historii commitů.

Porozumění tomuto modelu — klíč k efektivní práci s Gitem. Vývojář může selektivně připravit k commitu pouze část změněných souborů, čímž vytváří logicky ucelené commity s jasným popisem.

Populární platformy pro ukládání repozitářů

Vzdálené repozitáře jsou obvykle hostovány na specializovaných platformách, které poskytují webové rozhraní, systém správy přístupu a další nástroje pro společný vývoj.

• GitHub — největší platforma s více než 100 miliony repozitářů. Poskytuje Actions, Pull Requests, Issues a Wiki. Zdarma pro veřejné projekty.
• GitLab — platforma s integrovaným CI/CD, Container Registry a vestavěným DevOps pipeline. K dispozici jako SaaS a self-hosted verze.
• Bitbucket — řešení od Atlassian s integrací Jira a Trello. Populární v podnikovém prostředí díky flexibilnímu nastavení přístupu.

Výběr platformy závisí na velikosti týmu, požadavcích na soukromí a potřebných integracích. Pro vývoj mobilních aplikací je často volen GitHub díky široké podpoře komunity a integraci s CI/CD nástroji pro iOS a Android.

Příklady příkazů pro práci s repozitářem

Podívejme se na praktický scénář: vývojář klonuje existující repozitář, vytvoří novou větev, provede změny a odešle je na server. Každý příkaz demonstruje práci s různými komponentami repozitáře.

# Klonování vzdáleného repozitáře
git clone https://github.com/user/mobile-app.git

# Přechod do adresáře projektu
cd mobile-app

# Vytvoření nové větve feature a přepnutí na ni
git checkout -b feature/auth

# Kontrola stavu změněných souborů
git status

# Přidání všech změn do staging area
git add .

# Vytvoření commitu s popisem
git commit -m "Add authentication module"

# Odeslání změn do vzdáleného repozitáře
git push origin feature/auth

Příkaz git status — jeden z nejužitečnějších v každodenní práci. Ukazuje, které soubory byly změněny, které jsou připraveny k commitu a které nejsou Gitem vůbec sledovány.

Prohlížení historie commitů

Pro analýzu historie repozitáře se používá příkaz git log s různými přepínači formátování. Zobrazuje chronologii commitů, jejich autory, data a SHA-1 identifikátory.

# Zobrazení historie s vizualizací grafu větví
git log --oneline --graph --all

# Zobrazení změn v konkrétním commitu
git show a1b2c3d

# Porovnání aktuálního stavu s posledním commitem
git diff HEAD

# Zobrazení historie konkrétního souboru
git log --follow src/MainActivity.kt

Přepínač --graph zobrazuje ASCII graf větvení, což je užitečné zejména v repozitářích s aktivní prací ve více větvích. U mobilních projektů s častými vydáními vizuální graf pomáhá rychle posoudit strukturu vývoje.