Kontrola wersji z Claude Code: commity, konflikty, PR-y i worktree

Claude Code obsługuje git przez narzędzie Bash, więc kontrola wersji staje się rozmową: na starcie sesji dostaje migawkę stanu repozytorium, dzieli zmiany na commity w formacie zespołu, wyjaśnia i rozwiązuje konflikty, otwiera pull requesty przez GitHub CLI i izoluje równoległe sesje poleceniem claude --worktree. Każdej zmiany dowodzą testy i review, nie opis commita.

Ta strona jest dla programistów, którzy używają już Claude Code w prawdziwym repozytorium. Od dwóch godzin pracujesz nad funkcją, która obejmuje siedem plików, a w drzewie roboczym leży jeszcze poprawka błędu zauważonego po drodze i refaktoryzacja, której nie umiałeś sobie odmówić. Chcesz trzech czystych commitów, PR-a, którego recenzent zatwierdzi bez czytania każdej linii, i drugiej sesji, która przygotowuje hotfix, podczas gdy pierwsza pracuje dalej. Strona zakłada, że pracujesz już w pętli eksploracja, plan, kod i weryfikacja; tutaj wynik tej pętli zamienia się w historię repozytorium.

Co zyskasz na pracy z gitem w Claude Code

• Blok w CLAUDE.md i politykę uprawnień, dzięki którym Claude commituje po twojemu i pyta przed pushem, także w trybie auto.
• Cztery prompty do skopiowania: podział splątanych zmian, rozwiązywanie konfliktów, PR z dowodami i szukanie regresji przez git bisect.
• Plugin commit-commands do commitów i PR-ów jednym poleceniem oraz wiedzę, kiedy go nie używać.
• Równoległe sesje w worktree przez claude --worktree, razem z .worktreeinclude i sprzątaniem.
• Sposoby wyjścia z typowych wpadek przy pracy agenta z gitem oraz odpowiedź, kto zatwierdza zmianę przed merge.

Co Claude Code wie o twoim repozytorium

Gdy startuje lokalna rozmowa, Claude Code przekazuje Claude’owi migawkę stanu gita: bieżącą gałąź, wynik git status i ostatnie commity. Ładuje też wbudowane instrukcje pisania commitów i pull requestów. Możesz więc zacząć od „commit my changes” zamiast wklejać diff.

W praktyce liczą się dwa szczegóły:

• Migawka nie jest aktualizowana na bieżąco. Claude Code tworzy ją na starcie sesji i odświeża po kompaktowaniu kontekstu (od v2.1.269), a nie po każdym poleceniu. Jeśli przełączysz gałąź albo zrobisz commit w innym terminalu, Claude pracuje na nieaktualnym stanie, dopóki znowu nie uruchomi git status. Po każdej zmianie zrobionej poza sesją napisz „re-read the git state first”.
• Commity mają atrybucję. Domyślnie Claude Code dodaje do commitów trailer Co-Authored-By, a do opisów PR linię „Generated with Claude Code”. Zmienisz lub ukryjesz je ustawieniem attribution ("attribution": false wymaga v2.1.281 lub nowszej). Starsze wersje pomijają plik ustawień, który je zawiera, więc we wspólnym .claude/settings.json użyj formy obiektowej, na przykład "attribution": { "commit": "", "pr": "", "sessionUrl": false }. includeGitInstructions: false ustaw tylko wtedy, gdy własny skill gitowy zastępuje wbudowane instrukcje; to ustawienie usuwa też migawkę stanu gita, więc twój skill powinien sam uruchamiać git status.

Ustaw raz zasady commitów i uprawnienia gita

Konwencje zespołu wpisz do CLAUDE.md, żeby każda sesja stosowała je bez przypominania. Gdzie leży ten plik i jak się ładuje, opisuje przewodnik po plikach pamięci Claude Code.

## Git rules
- Conventional commits: feat, fix, docs, refactor, test, chore, with a scope: feat(auth): add OAuth flow
- Subject line under 72 characters; body explains why, not what
- One logical change per commit; never mix a refactor with a behaviour change
- Run `npm test` before every commit and paste the summary line into the commit body
- Never use --no-verify, never amend or force-push a pushed commit, never commit to main
- Reference the issue: Closes #123

Potem zdecyduj, co Claude może zrobić bez pytania. Ten .claude/settings.json pozwala swobodnie commitować, każdy push zamienia w pytanie i odrzuca force push:

{
  "permissions": {
    "allow": ["Bash(git add *)", "Bash(git commit *)"],
    "ask": ["Bash(git push *)"],
    "deny": ["Bash(git push --force *)", "Bash(git push -f *)"]
  }
}

Uwaga

Reguły Bash dopasowują polecenie w takiej postaci, w jakiej zostało zapisane. git -C . push, git push origin main --force ani git push --force-with-lease nie pasują do wzorców powyżej, więc traktuj je jako zabezpieczenie przed typowym zapisem, a nie granicę bezpieczeństwa. Chroń main także regułami ochrony gałęzi na serwerze. Składnię reguł i tryby opisuje sekcja o uprawnieniach w przewodniku po konfiguracji.

To, które z tych reguł faktycznie działają, zależy od trybu uprawnień. Od Claude Code v2.1.283 (oba kanały wydań na 2026-10-12) tryb auto jest trybem startowym interaktywnych sesji w terminalu na modelach, które go obsługują (zobacz przewodnik po konfiguracji), a w trybie auto push do dowolnej gałęzi twojego repozytorium i otwarcie pull requesta zgodnego z twoją prośbą odbywają się bez pytania. To reguła ask powyżej przywraca ludzki punkt kontrolny przed każdym pushem, bo tryb auto nadal pokazuje pytania wymuszone regułą ask. Klasyfikator trybu auto domyślnie blokuje też force push, git reset --hard, git clean -fd i amend commita, który już wypchnięto, a reguły deny blokują w każdym trybie, także w bypassPermissions. W jakim trybie startuje sesja, wyjaśnia przewodnik po konfiguracji.

Hooki samego gita działają także wtedy, gdy commituje Claude. Jeśli repozytorium ma hook pre-commit, który uruchamia linter i szybkie testy, przez tę bramkę przechodzi każdy commit agenta — to najtańsza weryfikacja, jaką masz.

Podziel splątane zmiany na czyste commity

Zanim powstanie jakikolwiek commit, poproś o plan. Na etapie planu wyłapiesz poprawkę błędu ukrytą w refaktoryzacji.

Prompt do skopiowania: podział zmian na zweryfikowane commity

Re-read the git state, then split my uncommitted changes into logical commits.

1. Group every changed hunk by purpose (feature, bug fix, refactor, tests). A file may
   belong to more than one group. Stage individual hunks non-interactively: write each
   hunk to a patch file and apply it with `git apply --cached <patch>` (never `git add -p`,
   which is interactive).
2. Show me the plan as a table: commit message, files and hunks, and why they belong together.
3. Wait for my approval.
4. For each commit in order: stage only its hunks, then hide everything that is not staged
   with `git stash push --keep-index --include-untracked`, run `npm test`, commit only if
   the tests pass, and run `git stash pop`. If a commit fails the tests on its own, stop
   and tell me which change it depends on instead of merging the groups.
5. Verify the whole series with `git rebase --exec "npm test" <base>`, where <base> is the
   commit you started from.
6. Finish with `git log --oneline -5` and `git status` so I can see nothing is left over.

Historia jest wiarygodna dzięki krokom 4 i 5. npm test działa na drzewie roboczym, więc bez stasha niezaindeksowane hunki kolejnych grup nadal leżałyby na dysku, a commit działający tylko razem z nimi przeszedłby testy. Gdy wszystko inne jest schowane, każdy commit jest testowany dokładnie w takiej postaci, w jakiej ktoś go później przełączy (checkout), a git rebase --exec uruchamia testy ponownie na każdym commicie gotowej serii, więc git bisect i git revert działają także później. Wynik sprawdzasz, czytając tabelę planu i końcowy git log, a nie diffy.

Przed pierwszym commitem większej zmiany uruchom w sesji /code-review. Sprawdza commity twojej gałęzi, których nie ma jeszcze w upstreamie, oraz niezacommitowane zmiany pod kątem błędów poprawności w subagencie działającym w tle, /code-review --fix od razu nanosi poprawki, a /code-review high 1234 zamiast tego recenzuje pull request 1234. Proponuje też porządki: ponowne użycie istniejącego kodu i uproszczenia; wpisany poziom (high) staje się domyślny dla kolejnych uruchomień /code-review, dopóki nie wpiszesz innego. Poprawki z --fix powstają poza checkpointami, więc cofasz je gitem, a nie przez /rewind. /security-review porównuje gałąź z domyślną gałęzią origin i szuka podatności.

Commity i PR-y jednym poleceniem: plugin commit-commands

Plugin commit-commands od Anthropic pakuje typowe przepływy w trzy polecenia z przestrzenią nazw. Zainstaluj go raz z powłoki:

claude plugin install commit-commands@claude-plugins-official

Polecenie	Co robi
/commit-commands:commit	Czyta git status, git diff HEAD i ostatnie commity, potem tworzy jeden commit w stylu repozytorium
/commit-commands:commit-push-pr	Tworzy gałąź, jeśli jesteś na main, robi jeden commit, wypycha go do origin i uruchamia gh pr create
/commit-commands:clean_gone	Usuwa lokalne gałęzie, których zdalny odpowiednik zniknął, razem z ich worktree

Polecenia pluginu wpisuj z przestrzenią nazw, tak jak w tabeli. Polecenie commit-push-pr wymaga GitHub CLI (gh) z zalogowanym kontem.

Przed użyciem commit-push-pr poznaj dwa kompromisy. Wszystko trafia do jednego commita, więc splątaną pracę najpierw podziel promptem z poprzedniej sekcji. Plik polecenia z góry zatwierdza git push i gh pr create na czas tej tury. Bez reguły ask push odbywa się bez pytania. Z regułą ask z wcześniejszej sekcji Claude nadal zapyta, bo reguły ask mają pierwszeństwo przed takimi zgodami. Tak czy inaczej, testy uruchom przed wpisaniem polecenia. Pamiętaj też, że clean_gone usuwa worktree siłowo (git worktree remove --force) i kasuje gałęzie przez git branch -D: najpierw zacommituj lub wypchnij wszystko, czego potrzebujesz z tych worktree.

Rozwiąż konflikty merge i rebase bez gubienia żadnej strony

Przy konfliktach wyjaśnienie jest warte więcej niż samo rozwiązanie. Poproś o jedno i drugie.

Prompt do skopiowania: wyjaśnij i rozwiąż konflikty

I am rebasing this branch onto main and have conflicts. For each conflicted file:

1. Explain in two sentences what main changed and what my branch changed, using
   `git log --oneline main -- <file>` and the conflict markers.
2. Say whether one side supersedes the other or both must be kept, and why.
3. Show the proposed resolution as a diff and wait for my approval.

After all files are resolved, run the full test suite, including the tests that main
added. Do not run `git rebase --continue` until they pass. If a test from main fails,
report it: that means my branch broke behaviour main depends on.

Typowa odpowiedź brzmi: „Main dodał rate limiting do handlera logowania, a twoja gałąź podzieliła handler na mniejsze funkcje. Zachowaj oba: przenieś sprawdzanie limitu do nowej funkcji validateLogin”. Rozwiązanie weryfikujesz testami dodanymi w main, bo to one zapisują, co autorzy zmian w main chcieli osiągnąć, oraz poleceniem git range-diff:

# Run straight after `git rebase --continue` finishes: old base..old tip vs new base..new tip
git range-diff "$(git merge-base ORIG_HEAD main)..ORIG_HEAD" main..HEAD

Pierwszy zakres to twoja gałąź sprzed rebase (od starej bazy do jej ostatniego commita), drugi to gałąź po rebase (od nowej bazy do jej ostatniego commita), więc commity, które w międzyczasie doszły do main, nie zaśmiecają wyniku. Commit, który podczas rebase zmienił się w nieoczekiwany sposób, od razu rzuca się w oczy, bez czytania całego diffa. Uruchom to polecenie, zanim cokolwiek innego nadpisze ORIG_HEAD; jeśli podczas rozwiązywania konfliktów użyłeś git reset, ORIG_HEAD został nadpisany, więc zamiast niego użyj wpisu z reflogu gałęzi (<gałąź>@{1}).

Otwórz pull request, który recenzent może zweryfikować

„Create a PR” daje ogólnikowy opis. Recenzent, który nie zamierza czytać każdej linii, potrzebuje dowodów: jakie zachowanie się zmieniło, jak to przetestowano i co może się zepsuć.

Prompt do skopiowania: PR z dowodami

Prepare this branch for review against main.

1. Run the full test suite, the type check and the linter. If anything fails, stop and
   show me the failure instead of opening the PR.
2. Run /code-review on the branch and fix anything it reports as a correctness bug.
3. Push the branch and open the PR with `gh pr create`. The description must contain:
   - Summary: 2-3 bullets on the behaviour that changed, from the user's side
   - Evidence: the commands you ran and their pass/fail summary lines
   - Risk: what could break, which files hold the risky logic, and how to roll back
   - Migration steps, if any, and "Closes #<issue>" if the branch name contains one
4. Print the PR URL.

Gdy Claude tworzy PR przez gh pr create, Claude Code łączy sesję z tym PR-em. Kiedy przyjdą uwagi z review, wrócisz do tego samego kontekstu:

claude --from-pr 1234

--from-pr otwiera wybór sesji przefiltrowany do sesji powiązanych z danym PR-em i przyjmuje też adres URL PR-a.

Wszystko na tej stronie załatwia gh. Serwer MCP GitHuba dodaj wtedy, gdy Claude ma czytać wątki review, logi Actions i issues jako ustrukturyzowane wywołania narzędzi, a nie parsować wyjście gh.

Kto zatwierdza zmianę przed merge?

Recenzent zatwierdza PR na podstawie sekcji Evidence i Risk, a nie czytania linia po linii, a bramką merge jest CI. Wymuś to po stronie serwera: ustaw te same zadania testów, sprawdzania typów i lintera jako wymagane status checks na main, żeby PR, którego sekcję Evidence napisał agent, nie mógł trafić do main, dopóki CI tego nie powtórzy. Zadanie recenzenta to sprawdzić, czy Evidence opisuje zachowanie, o które prosiło issue, czy Risk podaje sposób wycofania zmiany i czy CI jest zielone. Review, które skaluje się poza jednego recenzenta, opisuje automatyczne code review z Claude Code. Dlaczego warto czytać dowody zamiast diffów, wyjaśnia strona dowody zamiast czytania kodu.

Uruchom równoległe sesje w git worktree

Dwie sesje edytujące ten sam checkout nadpisują sobie nawzajem pliki. Worktree daje każdej sesji własny katalog i gałąź przy wspólnej historii repozytorium.

1. Uruchom sesję we własnym worktree. W terminalu, w katalogu głównym repozytorium:

   claude --worktree notifications   # creates .claude/worktrees/notifications/ on branch worktree-notifications
   claude -w                         # no name: Claude Code generates one
   claude --worktree "#1234"         # fetch pull request 1234 into .claude/worktrees/pr-1234 (quote the #)

   Drugą izolowaną sesję uruchomisz tym samym poleceniem z inną nazwą w drugim terminalu. Najpierw uruchom raz claude w repozytorium i zaakceptuj okno zaufania do obszaru roboczego (workspace trust); inaczej --worktree kończy się błędem.

2. Ukryj worktree przed git status. Dopisz .claude/worktrees/ do .gitignore.

3. Skopiuj lokalne pliki potrzebne do startu aplikacji. Worktree to świeży checkout, więc brakuje w nim ignorowanych plików, takich jak .env. Wypisz je w .worktreeinclude w katalogu głównym repozytorium, w składni .gitignore:

   .env.local
   config/dev-settings.json

   Kopiowane są tylko pliki, które pasują do wzorca i są ignorowane przez gita; pliki śledzone nigdy. Każdy skopiowany plik trafia do każdego worktree i może go przeczytać każdy agent, który tam pracuje. Prawdziwe dane uwierzytelniające trzymaj w menedżerze sekretów, a nie w pliku, który rozsyłasz.

4. Wybierz gałąź bazową. Nowe worktree odgałęziają się od domyślnej gałęzi zdalnej (worktree.baseRef: "fresh"). Ustaw "worktree": { "baseRef": "head" }, gdy worktree ma zawierać twoją niewypchniętą pracę.

5. Wyjdź i posprzątaj. Przy wyjściu Claude Code automatycznie usuwa czyste worktree razem z gałęzią, jeśli sesja nie ma nazwy. Najpierw pyta, gdy nadałeś sesji nazwę (-n lub /rename) albo worktree zawiera zmiany lub nowe commity; jeśli je zachowasz, Claude Code wypisze polecenie claude --worktree <name> --resume, którym do niego wrócisz. Claude Code nie sprząta worktree z uruchomień claude -p: usuń je poleceniem git worktree remove, a jeśli git zgłosi, że worktree jest zablokowane, najpierw uruchom git worktree unlock.

Aby pobrać konkretną istniejącą gałąź albo umieścić worktree poza repozytorium, użyj gita bezpośrednio: git worktree add ../myapp-hotfix hotfix/auth-timeout, a potem uruchom claude w tym katalogu. Wiele sesji naraz wymaga też osobnych portów i kolejki review; oba tematy omawiają przewodnik po równoległych agentach i lista kontrolna izolacji worktree.

Wznów właściwą sesję po zmianie gałęzi

Sesja należy do katalogu, nie do gałęzi. Po git switch rozmowa trwa dalej, ale Claude czyta już pliki innej gałęzi, a migawka gita z początku sesji jest nieaktualna.

claude -c                                # most recent conversation in this directory
claude --resume auth-refactor            # a named session
claude --continue --fork-session         # same history, new session ID

Wznowienie tej samej sesji w dwóch terminalach bez --fork-session przeplata obie rozmowy w jednym zapisie. --fork-session wybierz, gdy chcesz spróbować dwóch podejść od tego samego punktu, a worktree, gdy oba podejścia nie mogą dotykać tych samych plików.

Znajdź w historii gita moment zmiany zachowania

Historia to dowód. Bisect prowadzony przez nieprzechodzący test wskazuje commit, który coś zepsuł, i nikt nie musi czytać commitów po drodze.

Prompt do skopiowania: znajdź regresję przez git bisect

Checkout totals are wrong for orders with a discount code: expected 90.00, got 100.00.

1. Write a failing test in tests/checkout/discount.test.ts that reproduces this, and
   confirm it fails on HEAD. Keep the test file uncommitted during the bisect.
2. Find a commit from the last 30 days where the test passes.
3. Run `git bisect start HEAD <good-commit>` and `git bisect run npx vitest run
   tests/checkout/discount.test.ts`. If the test cannot run on a commit (for example,
   a missing module), wrap it in a script that exits 125 so bisect skips that commit.
4. Report the first bad commit, its diff for the relevant files, and one sentence on why
   it broke discounts. Then run `git bisect reset`. Do not fix anything yet.

Przy prostszych pytaniach zapytaj wprost: „When did the session timeout in @src/lib/auth.ts last change? Show the commit and the diff.”

Gdy praca z gitem w Claude Code idzie źle

Claude zacommitował pliki, których nie chciałeś. Jeśli commit nie jest wypchnięty, uruchom git reset --soft HEAD~1: commit znika, a zmiany zostają w indeksie (staged). Następnym razem nazwij zakres: „commit only the files in src/api/”, albo sam zrób git add i napisz „commit what is staged, nothing else”.

Rebase albo push poszedł źle. /rewind nie cofa operacji gita: checkpointy nie śledzą zmian wprowadzonych poleceniami Bash, a push dzieje się poza twoim komputerem. Ratunek jest w gicie. git rebase --abort przerywa trwający rebase; git reflog pokazuje każde położenie gałęzi, a git reset --hard <sha> przywraca jedno z nich, gdy sprawdzisz je wcześniej przez git show. Zachowaj reguły deny dla force push i ochronę gałęzi main.

Rozwiązanie konfliktu zgubiło logikę jednej strony. Twoją kontrolą są testy dodane w main; jeśli przechodzą, a logiki nadal brakuje, main nie miał na nią testu. Powiedz Claude’owi dokładnie, czego brakuje („the rate-limit check from main is gone; keep it inside validateLogin”), a potem poproś o test, który to pokrywa, żeby kolejny rebase nie mógł tego zgubić.

Commit ominął hooki albo opis ignoruje wasz format. Claude stosuje się do CLAUDE.md, więc sprawdź, czy jest tam reguła i czy mówi „never use —no-verify”. Opis niewypchniętego commita poprawisz promptem „rewrite the last commit message as a conventional commit with scope” (to jest amend; nigdy nie rób tego po pushu).

Sesja w worktree nie uruchamia aplikacji. Brakuje pliku .env albo pliku generowanego: dopisz go do .worktreeinclude i utwórz nowe worktree. Jeśli pliki binarne są w worktree tylko małymi plikami-wskaźnikami LFS, Git LFS skonfigurowano poleceniem git lfs install --local: Claude Code przy tworzeniu worktree pomija sterowniki filtrów z konfiguracji repozytorium, więc uruchom w nim git lfs pull. Jeśli dwa worktree walczą o port 3000, daj każdemu port przez jego środowisko. git worktree list pokazuje, co istnieje, a po ręcznym usunięciu katalogów uruchom git worktree prune.

claude --from-pr niczego nie znajduje. Claude Code wiąże sesję z PR-em, gdy Claude tworzy ten PR poleceniem gh pr create w tej sesji. PR otwarty przez ciebie nie ma powiązanej sesji: uruchom claude --resume i naciśnij Ctrl+B, żeby zawęzić wybór do sesji z bieżącej gałęzi, albo zacznij od nowa na commicie PR-a poleceniem claude --worktree "#1234".

Claude zrobił push, choć spodziewałeś się pytania. Sesja działała w trybie auto, a ustawienia nie mają reguły ask dla git push, albo polecenie zapisano inaczej niż w regule (git -C . push). Dodaj regułę ask, sprawdź ją poleceniem /permissions, a to, co nigdy nie może trafić do main, zablokuj regułami ochrony gałęzi na serwerze.

Dokąd dalej po kontroli wersji

Workflow PRD Następny krok: z dokumentu wymagań do kryteriów akceptacji, zapisanego planu i zadań z bramką testów na każdym.

Workflow programistyczny Pętla eksploracja, plan, kod i weryfikacja, z której biorą się te commity.

Wychodzenie z błędów Checkpointy, /rewind i przywracanie sesji na właściwe tory.

Automatyczne code review Agenci review i kontrole CI, które weryfikują PR, zanim zrobi to człowiek.

Równoległi agenci w worktree Porty, konfiguracja, testy i sprzątanie dla dwóch do czterech agentów naraz.

Używasz innego narzędzia? Te same przepływy w Codex opisują integracja Codex z GitHubem i worktree w Codex; w Cursorze zajrzyj do checkpointów i gałęzi.