Commitovat — co to je, pravidla formátování a práce s Git

Co je commit v Git

Commit v Git je objekt, který ukládá stav souborů projektu v určitém okamžiku. Každý commit obsahuje snímek všech sledovaných souborů, odkaz na rodičovský commit a metadata. Na rozdíl od jiných systémů správy verzí Git používá content-addressable storage — každý objekt je identifikován hash SHA-1 svého obsahu.

Když vývojář commitne změny, Git vytvoří commit objekt, který ukládá: tree objekt (struktura souborů), hash rodičovského commitu, autora, komitera, datum a zprávu. Tento objekt je neměnný — po vytvoření nelze commit upravit bez změny jeho hashe. Právě neměnnost zaručuje integritu historie projektu.

# Připrav změny a commitni
git add index.html style.css
git commit -m "Fix responsive layout on mobile devices"

# Zobrazit podrobnosti commitu
git log --oneline -3
git show HEAD

# Připrav všechny změny a commitni v jednom kroku
git commit -a -m "Update dependencies to latest versions"

Commity tvoří orientovaný acyklický graf (DAG), kde každý nový commit odkazuje na předchozí. To umožňuje pohyb v historii, rušení změn a analýzu vývoje kódové základny. Pochopení struktury Git DAG — základ pro pokročilou práci s commity.

Jak správně commitovat změny

Proces commitu v Git se skládá ze dvou fází: přidání změn do staging area (indexu) a vytvoření commitu. Staging area umožňuje vývojáři vybrat, které změny vstoupí do commitu, i když bylo v pracovním adresáři změněno mnoho souborů.

Pravidlo atomicity — klíčový princip dobrého commitu. Každý commit by měl obsahovat jednu logickou změnu. Pokud vývojář opravuje chybu a refaktoruje kód — jsou to dva různé commity. Atomické commity zjednodušují code review, vracení změn a analýzu historie.

Před commitováním stojí za kontrolu: zda v kódu nezůstal ladicí výstup, zakomentované bloky nebo náhodné změny. K tomu slouží příkaz git diff --cached, který ukazuje, co přesně vstoupí do commitu. Dodatečná kontrola přes git status zobrazuje seznam souborů ve staging area.

• Zkontroluj změny — git diff --cached ukazuje co vstupuje do commitu
• Zkontroluj kvalitu — kód by měl projít linterem a testy před commitem
• Napiš zprávu — srozumitelný popis účelu změny
• Zkontroluj staged — git status potvrzuje seznam souborů

Pravidla psaní zpráv commitů

Zpráva commitu — dokumentace změny pro budoucí vývojáře. Dobrá zpráva odpovídá na otázky: co bylo změněno a proč. Konvence Conventional Commits (tým Angular, 2016) se stala standardem pro mnoho projektů a definuje formát: typ(oblast): popis.

Dobrá zpráva commitu se skládá z nadpisu (do 50 znaků) a těla (volitelné, do 72 znaků na řádek). Nadpis se píše v rozkazovacím způsobu: „Add” ne „Added” nebo „Adds”. Velké písmeno a tečka na konci nadpisu se nepoužívají — to je mezinárodní dohoda Git.

Špatná zpráva: „fix things” nebo „update” — nenese informaci. Za měsíc vývojář nebude schopen pochopit, co přesně bylo změněno a proč. Dobrá zpráva: „fix(payment): handle timeout in stripe callback” — okamžitě jasné, kde a co bylo opraveno.

Časté chyby při commitech

Vývojáři, zejména začátečníci, často dělají typické chyby při commitech. Nejčastější — příliš velký commit, ve kterém je smícháno desítky změn. Takový commit nelze částečně vrátit a code review se stává utrpením.

Druhá nejčastější chyba — špatná zpráva commitu. Zprávy typu „fix”, „update”, „changes” nebo „wip” nedávají kontext budoucím vývojářům. Za půl roku si nikdo nebude pamatovat, co přesně bylo opraveno. Pravidlo je jednoduché: představ si, že za rok se díváš do historie a snažíš se najít konkrétní změnu.

Třetí chyba — commit nezkompilovaného nebo nefunkčního kódu. Po commitu by se kód měl alespoň zkompilovat. Nerozbitý build — základní požadavek na každý commit do společné větve. K tomu se před commitem spouští sestavení a testy.

Čtvrtá chyba — commit s důvěrnými údaji. API klíče, hesla a tokeny by se neměly dostat do historie Git. Pokud už bylo tajemství commitnuto, nestačí jej jednoduše smazat v novém commitu — je třeba jej smazat z celé historie pomocí git filter-branch nebo BFG Repo-Cleaner.

Pokročilé techniky práce s commity

Git poskytuje nástroje pro správu historie commitů. Jedním z nejužitečnějších je git commit --amend, který umožňuje doplnit poslední commit o nové změny nebo opravit zprávu. To je vhodné, pokud vývojář zapomněl zahrnout soubor nebo udělal chybu ve zprávě.

# Opravit poslední zprávu commitu
git commit --amend -m "fix(auth): correct token validation logic"

# Přidat vynechaný soubor k poslednímu commitu
git add missed-file.txt
git commit --amend --no-edit

# Interaktivní rebase pro poslední 3 commity
git rebase -i HEAD~3

Interactive rebase — mocný nástroj pro přepisování historie. Umožňuje spojovat commity (squash), měnit zprávy (reword), měnit pořadí (reorder) a mazat commity (drop). Rebase však mění historii, proto se aplikuje pouze na lokální commity, které ještě nebyly odeslány do vzdáleného repozitáře.

Pro rušení commitů existují dva přístupy. git revert vytváří nový commit, který ruší změny předchozího — bezpečný způsob zachovávající historii. git reset maže commity z historie — nebezpečný, pokud byly commity již odeslány. V týmovém vývoji se používá pouze git revert pro rušení publikovaných commitů.