Git je dnes v podstatě standard, jak ukládat zdrojový kód.

Chce-li člověk programovat, nemá moc možnost se Gitu vyhnout. Možná v bance se může setkat se Subversion (SVN) nebo v herním průmyslu s Perforce (Helix Core).

Git původně vznikl jako sada příkazů pro příkazovou řádku (CLI – command line interface), ale postupem času nad tím vznikla řada aplikací nabízejících grafické rozhraní (GUI – graphical user interface).

CLI, nebo GUI?

Opravdoví programátoři nepochybně používají Git v příkazové řádce. Osobně se ale domnívám, že vyšší efektivity a nižší chybovosti jde dosáhnout spíš v Git klientu s grafickým rozhraním.

Osobně mi nejvíc vyhovuje GitHub Desktop. Jde v něm snadno vyřešit drtivá většina úkonů, co je potřeba, aniž by se příliš často dostával do neřešitelných stavů.

Další výhoda je napojení na GitHub, díky čemuž z něj jde snadno klonovat repozitáře.

Git v editoru/IDE

Dost praktické je používat Git klienta v oblíbeném editoru.

Dle mého názoru nejlépe funguje vestavěný Git v IDE od JetBrains.

Kontrolu vlastního kódu mi ale přijde lepší provádět v jiném zobrazení, než ve kterém kód vznikl, protože to člověku trochu naruší slepotu.

Něco mezi je nástroj typu Magit, pro vyznavače příkazové řádky to může být zajímavé řešení.

Git přes AI

Git jde dost dobře používat i přes nějakého AI chatbota. Třeba přes Cursor. Pokud se mu umožní spouštět příkazy v příkazové řádce, jde mu lidským způsobem popsat, co má dělat.

Dost užitečné je to k řešení konfliktů v kódu, což je typicky rutinní otravná činnost, kterou jazykový model snadno zvládne.

Užitečné příkazy

Doporučuji Git používat přes grafické rozhraní a většinu věcí klikat. Přijde mi to rychlejší s nižší chybovostí. Některé věci ale naklikat neumím, a proto používám následující příkazy:

git reset --hard origin/main

Tvrdý reset na vzdálenou main (nebo jinou) větev. Na konkrétní commit: git reset --hard <HASH>.

git rebase --onto origin/nazev-vetve HEAD~

Vychází-li můj kód z cizí větve, kde někdo změní historii, klasický rebase může znamenat konflikty. Tento příkaz bere v úvahu jen poslední commit (typicky můj), který hodí nad aktualisovanou cizí větev.

git rebase --abort

Když se při rebaseování a řešení konfliktů něco pokazí, tímto se to ukončí.

git cherry-pick <HASH>

Vezme konkrétní commit z jiné větve a aplikuje ho sem. Ideální pro rychlé převzetí bugfixu bez merge celé větve.

Commit zprávy

Doporučuji moc neřešit, nezdržovat se tím, ideálně nechat vygenerovat AI nebo převzít identifikátor a název ticketu, používá-li se nějaký takový systém na projektu.

Squashování commitů

V některých případech se hodí sloučit více commitů do jednoho.

Pořádek v commitech a historii

Když se člověk trochu naučí s Gitem, může mít tendenci se snažit o perfektní Git historii. Tj. rozdělovat části kódu do více smysluplných commitů v rámci jedné feature branche, squashovat commity a podobně.

Časem jsem došel k tomu, že Git historie je často přeceňovaná. Důležitější než „dokonalé“ atomické commity je rychlá a bezpečná integrace změn a srozumitelný popis v PR. Prakticky se mi osvědčilo:

• Malé PR s jasným cílem a popisem. Snadněji se reviewuje a revertuje.
• Na feature větvi klidně „WIP“ commity; před merge do hlavní větve použít v GitLabu/GitHubu squash, ať je výsledek přehledný.
• Po začátku review už historii větve nepřepisovat; případné opravy přidat navrch jako !fixup commity.

Stručně řečeno v rámci merge/pull requestu může být v commitech nepořádek, který se vyřeší squashnutím a změnou commit message.

Rebase vs. merge

Rebase přepisuje historii tak, že mé commity přehrává na aktuální vrchol cílové větve. Výsledek je čistá, lineární historie.

Merge zachovává původní historii a vytvoří merge commit.

Osobně mi přijde přehlednější používat rebase.

Záchrana přes git reflog

git reflog ukazuje všechny nedávné pohyby HEAD. Když se „ztratí“ commit po rebase/resetu, téměř vždy je v reflogu dohledatelný.

git reflog
git checkout <HASH_Z_REFLOGU>
git branch zachrana/<popis>

Pro návrat celé větve na starý stav: git reset --hard <HASH>. Reflog je lokální; po git gc se staré záznamy mohou čistit, proto zachraňovat co nejdřív.

Vyčištění Gitu

Pravidelné čištění udrží repozitář malý a svižný. Následující příkazy jsou běžná údržba, některé jsou destruktivní – pouštět jen s vědomím důsledků.

git fetch --prune

Odstraní neaktuální vzdálené sledované větve (smazané na originu).

git gc --prune=now

Úklid nepotřebných objektů a optimalizace balíků. Agresivnější varianta po expirování reflogu.

git reflog expire --expire=now --all

Okamžitě vyprázdní reflog, aby šlo následně uvolnit prostor přes git gc.

git clean -fdx

Smaže neversované soubory a adresáře včetně ignorovaných (build/artefakty). Používat jen, když je to žádoucí.

git-filter-repo, BFG

Trvalé odstranění velkých souborů či citlivých dat z historie. Po přepsání historie je nutné force push a koordinace s týmem.

Git LFS

Pro binární soubory. Migrace existující historie: git lfs migrate import --include="*.psd,*.zip".

GitHub, nebo GitLab?

• GitHub: největší ekosystém, Actions, Copilot, přehledné PR UI, snadná integrace a marketplace.
• GitLab: silné integrované DevOps (CI/CD, registry, issue tracking) v jednom, on‑prem varianta, detailní oprávnění.

Volba: veřejné/open‑source a rychlý start spíš GitHub. Firemní on‑prem all‑in‑one a detailní řízení přístupu spíš GitLab.

Více větví

Pracuje-li člověk s hodně větvemi zároveň, zajímavé řešení je GitButler, který dokáže mít aplikovaný všechen kód najednou, ale zároveň ho sekat na samostatné větve pro pohodlnější code review a integraci.

Řeší to přesně takový problém typu mám rozdělanou práci, přišel bug a chtěl bych ho rychle opravit.

Nepoužívat stash

Stash slouží k odkládání změn na později.

Myšlenka hezká, ale celé to zavání tím, že člověk na odložené změny zapomene. Lepší mi přijde i rozdělané změny commitnout.

Slouží Git jako záloha?

Git je versovací systém, ne plnohodnotná záloha. Umí skvěle chránit zdrojáky a historii, ale neřeší: dostupnost (off‑site kopie), snapshoty celého prostředí, databáze, velké binárky mimo repo.

Rozumné může být používat zrcadlení mezi GitHubem a GitLabem.