Tahák: Git a GitHub s Claude Code

Claude Code umí obsloužit prakticky celý git a GitHub workflow — commity, větve, pull requesty, review i záchranu rozbitého repa. Tenhle tahák shrnuje, co mu po měsících denního používání svěřuji bez obav, a u každé situace ukazuje obojí: prompt, který píšu, i příkazy, které se pod kapotou reálně spustí. Protože delegovat neznamená přestat rozumět tomu, co se děje.

Commity a zprávy

Nejčastější věc, kterou po Claudovi chci. Stačí napsat „commitni to“ a pod kapotou proběhne:

git status                 # co je změněné a co untracked
git diff                   # co se skutečně změnilo
git add build.mjs serve.mjs
git commit -m "fix: dev server nepodával webp z podadresářů"

Zprávu píše podle toho, co se v diffu skutečně změnilo — ne podle mojí představy o tom, co jsem udělal. Co se mi osvědčilo:

• Konvence patří do CLAUDE.md. Jazyk commit zpráv, prefixy typu feat:/fix:, formát — jednou zapsat do instrukcí repozitáře a Claude je dodržuje bez připomínání.
• Selektivní commit funguje spolehlivě. Když mám rozdělaných víc věcí najednou:

commitni jen změny v build.mjs, zbytek nech být

Pod kapotou je to git add build.mjs a commit — žádné git add -A, které by s sebou vzalo i rozpracovaný zbytek.

• Nesouvisející změny nechám rozdělit. „Rozděl to do logických commitů“ — Claude si projde diff, seskupí soubory podle toho, co k čemu patří, a stageuje po skupinách (v krajním případě po hunkách přes git add -p).

Co si hlídám: push je vždycky explicitní krok. Claude mám instruovaný, ať nikdy nepushuje sám — commit je lokální a vratný, push už je publikace.

Zpátečka: amend, restore, stash

Drobné opravy, na které jsem dřív hledal přesný příkaz na Stack Overflow:

• „Přidej tohle do posledního commitu“:

git add build.mjs
git commit --amend --no-edit

Amend přepisuje historii — bezpečný je jen do chvíle, než commit pushnu. Claude na to upozorní sám, ale je dobré to vědět.

• „Zahoď změny v serve.mjs“:

git restore serve.mjs            # zahodí neuložené změny v souboru
git restore --staged serve.mjs   # jen vyndá ze stage, změny nechá

• „Ulož rozdělanou práci, potřebuju hotfix“:

git stash push -m "wip: nova paticka"
git stash list
git stash pop

Jen pozor: když git stash pop narazí na konflikt, změny aplikuje, ale stash nesmaže — schválně, ať o nic nepřijdete. Po vyřešení konfliktu ho ukliďte ručně: git stash drop.

Od té doby, co používám worktrees, stashuju míň — viz další sekce.

Větve a worktrees

Založení větve je jednoduché — „založ větev pro úpravu patičky“:

git switch -c feat/paticka

Zajímavější jsou worktrees: druhá pracovní kopie repozitáře na jiné větvi, ve vedlejším adresáři.

git worktree add ../projekt-oprava fix/prepocet-provizi
git worktree list
git worktree remove ../projekt-oprava   # až je hotovo

K čemu je to dobré s AI nástrojem: můžu mít dvě session Claude Code vedle sebe — jedna píše novou feature, druhá opravuje bug — a nešlapou si po souborech, protože každá pracuje ve vlastním adresáři. Bez přepínání větví a bez git stash akrobacie.

Dvě věci, které worktree nováčkovi neřekne: stejnou větev nejde mít checkoutnutou ve dvou worktrees najednou (git to odmítne — a dobře dělá). A node_modules se neklonují: každá kopie si žije vlastním životem, takže po git worktree add přijde ještě npm install.

(Worktrees řeší paralelní práci na jednom stroji. Jak udržet jeden projekt — včetně kontextu Claude Code — synchronizovaný mezi dvěma počítači, popisuje Jedno repo, dvě klávesnice.)

Pull requesty přes gh CLI

Claude Code používá GitHub přes oficiální gh CLI. Jednorázová příprava:

brew install gh            # macOS
winget install GitHub.cli  # Windows
sudo apt install gh        # Debian/Ubuntu
gh auth login              # jednorázové přihlášení

Pak stačí:

vytvoř PR proti main, popis stručně

Pod kapotou:

git log main..HEAD --oneline   # jaké commity větev přináší
git diff main...HEAD           # celý diff větve proti main
git push -u origin feat/paticka
gh pr create --base main --title "..." --body "..."

Popis PR vzniká ze skutečného diffu celé větve proti main, ne jen z posledního commitu — takže sedí i po deseti commitech s opravami. Druhý směr funguje taky:

načti review komentáře z PR #42 a zapracuj je

gh pr view 42 --comments                        # diskuze pod PR
gh api repos/{owner}/{repo}/pulls/42/comments   # inline komentáře v kódu

Claude si komentáře stáhne, projde je jeden po druhém a ke každému řekne, co s ním udělal. U komentářů, se kterými nesouhlasí, chci, aby to řekl — ne aby slepě vyhověl.

Review cizího PR — „stáhni PR #42 a projdi ho“:

gh pr checkout 42   # větev PR do lokální kopie
gh pr diff 42       # rychlý pohled bez checkoutu

A merge, když je hotovo — „mergni PR #42 squashem“:

gh pr merge 42 --squash --delete-branch

Merge beru stejně jako push: je to publikace, tak ho odklepávám explicitně.

Issues a CI

Sekce, kterou jsem v první verzi tohohle taháku vynechal — a přitom je to půlka toho, co gh denně dělá.

• „Vypiš otevřené issues s labelem bug“:

gh issue list --label bug --state open
gh issue view 12

• „Založ z tohohle issue“ — uprostřed session, když narazím na bug, který teď nechci řešit:

gh issue create --title "..." --body "..." --label bug

Popis píše Claude z kontextu session, dokud je čerstvý — takže je konkrétní: co se stalo, kde, jak to reprodukovat. Issue založené takhle je použitelnější než to, které bych psal z hlavy o tři dny později.

• „Proč spadla CI na téhle větvi?“ — možná největší časová úspora z celého taháku:

gh pr checks                        # stav checků na PR
gh run list --branch feat/paticka   # poslední běhy workflow
gh run view 1234567890 --log-failed # log jen toho, co selhalo

Claude si vytáhne log selhání, najde příčinu a rovnou navrhne opravu. Bez klikání do webového UI a scrollování kilometrovým logem.

Review vlastního diffu před PR

Než PR otevřu, nechám si diff projít ještě lokálně — je to levnější než pálit čas kolegy:

zreviduj diff téhle větve proti main — hledej chyby a rizika, ne styl

git diff main...HEAD

Tři tečky nejsou překlep: diff proti společnému předku (merge-base) ukáže jen to, co přinesla moje větev — ne změny, které mezitím přistály v main.

Funguje tím líp, čím konkrétnější zadání dostane: „zaměř se na ošetření chyb“, „hledej race conditions“, „zkontroluj, že se nikde neloguje osobní údaj“. Obecné „mrkni na to“ vrací obecné odpovědi.

Záchranné situace

Tady se pozná, jestli vám AI pomáhá, nebo škodí.

• Konflikty při merge/rebase — Claude je vyřeší, ale chci vidět zdůvodnění:

vyřeš konflikty; u každého souboru mi řekni, kterou stranu jsi vzal a proč

git status                        # které soubory jsou v konfliktu
git checkout --ours soubor.js     # vzít celou naši stranu
git checkout --theirs soubor.js   # vzít celou jejich stranu
git rebase --abort                # nouzová brzda: vrátit vše před rebase

Většinou ale Claude konfliktní bloky edituje ručně — je to přesnější než brát celé soubory jednou stranou. (A pozor na klasickou past: při rebase se význam --ours/--theirs otáčí.)

• Revert — bezpečná operace, vytváří nový commit, nic nepřepisuje:

git revert abc123

• Bisect — hledání commitu, který něco rozbil, je s AI konečně bezbolestné:

najdi bisectem commit, který rozbil build; testuj příkazem node build.mjs

git bisect start
git bisect bad                  # HEAD je rozbitý
git bisect good v1.4            # tady to ještě fungovalo
git bisect run node build.mjs   # automatický test každého kroku
git bisect reset

S git bisect run proběhne celé půlení bez jediného ručního kroku — Claude jen odečte výsledek a ukáže viníka.

• Reflog — poslední záchrana, když „tu včera byl commit a teď je pryč“:

git reflog                    # deník všeho, kde HEAD kdy byl
git reset --hard HEAD@{2}     # návrat na konkrétní stav

Čtení reflogu je bezpečné. Ten reset --hard na konci už ne — a tím jsme u pointy: git reset --hard, force push a mazání větví si dělám ručně, nebo minimálně chci, aby se Claude před provedením explicitně zeptal. Nastavení oprávnění v Claude Code tomu jde naproti: destruktivní příkazy nechávám na ručním schválení.

Rychlá reference

Závěr

Gitu kvůli Claudovi nepřestávám rozumět — právě naopak, bez toho bych nepoznal, kdy sáhne vedle. Jen už nemusím ručně psát příkazy, které umím nadiktovat, a ušetřenou energii dávám do kontroly výsledků. Git zůstává stejný, jen na klávesnici píše někdo jiný.