Kontrola Wersji: Integracja Git i Workflow PR

Claude Code obsługuje workflow git od początku do końca: generuje wiadomości commitów z faktycznego diffa przez claude commit, dzieli splątane zmiany na logiczne commity, wyjaśnia i rozwiązuje konflikty merge w prostym języku, tworzy pull requesty przez /commit-push-pr lub kontrolowany wieloetapowy flow oraz uruchamia równoległe sesje na git worktrees dla izolowanych stanów plików.

Pracowałeś nad funkcjonalnością przez dwie godziny. Implementacja obejmuje siedem plików w trzech katalogach. Teraz musisz wykonać commit — ale zmiany są splątane. Niektóre to nowa funkcjonalność, niektóre to poprawka błędu, którą zauważyłeś po drodze, a niektóre to refaktoryzacja, której nie mogłeś się oprzeć. Ręczne stagowanie fragmentów i pisanie spójnej wiadomości commita dla każdej logicznej zmiany zajęłoby piętnaście minut. Z Claude Code opisujesz, czego chcesz, a on zajmuje się hydrauliką git: stagowaniem odpowiednich plików, pisaniem wiadomości commitów na podstawie rzeczywistego diffa, dzieleniem zmian na logiczne commity i otwieraniem PR, gdy jesteś gotowy.

Ten przewodnik obejmuje workflow git, z którymi Claude Code radzi sobie najlepiej: commitowanie, branching, rozwiązywanie konfliktów, tworzenie PR i równoległy development z worktrees.

Co Wyniesiesz z Workflow Git

Workflow do czystych, logicznych commitów, nawet gdy Twoje zmiany są nieuporządkowane
Skróty claude commit i /commit-push-pr, które oszczędzają minuty przy każdym commicie
Prompty do rozwiązywania konfliktów merge, które faktycznie wyjaśniają, co się dzieje
Równoległy development oparty na worktrees z wieloma instancjami Claude
Workflow tworzenia PR, który łączy sesje z pull requestami

Jak Claude Code Widzi Twój Stan Git

Kiedy zaczynasz sesję, Claude automatycznie ma dostęp do Twojej obecnej gałęzi, niezcommitowanych zmian i historii ostatnich commitów. Nie musisz najpierw uruchamiać git status ani wklejać diffów — Claude odczytuje Twój stan git bezpośrednio. Oznacza to, że możesz zacząć od żądań wysokiego poziomu, takich jak “commituj moje zmiany”, a Claude rozgryzie szczegóły.

Tworzenie Czystych Commitów

Commit Jednym Poleceniem

Najprostszy workflow do commitowania:

claude commit

Claude odczytuje pełny diff wszystkich zmian staged i unstaged, generuje wiadomość commita na podstawie tego, co faktycznie się zmieniło (nie ogólnego opisu), i prosi o Twoje zatwierdzenie przed commitowaniem. Jeśli nic nie jest staged, Claude najpierw staguje wszystko.

Dla większej kontroli, poproś Claude interaktywnie:

Commituj moje zmiany z wiadomością conventional commit, która wyjaśnia,
co zostało dodane i dlaczego.

Claude:

Uruchomi git diff i git status, aby zobaczyć wszystkie zmiany
Przeanalizuje diff, aby zrozumieć intencję
Wygeneruje opisową wiadomość commita
Pokaże Ci wiadomość do zatwierdzenia
Uruchomi git commit po Twoim zatwierdzeniu

Dzielenie Splątanych Zmian

Gdy Twój katalog roboczy ma wiele niepowiązanych zmian, poproś Claude o ich rozdzielenie:

Prompt do skopiowania i wklejenia, aby podzielić zmiany na logiczne commity:

I have changes across multiple files. Split them into logical commits:

1. Look at all the changes and group them by purpose
2. For each group, stage only the relevant files
3. Write a conventional commit message for each group
4. Show me the plan before committing anything

Do not commit until I approve the grouping.

Claude bada każdy zmodyfikowany plik, identyfikuje, które zmiany należą razem (poprawka błędu vs. funkcjonalność vs. refaktoryzacja) i proponuje osobne commity. Sprawdzasz grupowanie i zatwierdzasz.

Konwencje Wiadomości Commitów

Jeśli Twój zespół używa konkretnego formatu commitów, umieść to w swoim CLAUDE.md:

## Commit Standards
- Use conventional commits: feat, fix, docs, refactor, test, chore
- Include scope in parentheses: feat(auth): add OAuth flow
- Keep subject line under 72 characters
- Add body with bullet points for multi-file changes
- Reference issue numbers: Closes #123

Claude będzie automatycznie przestrzegać tych konwencji, gdy znajdą się w pamięci Twojego projektu.

Zarządzanie Gałęziami

Tworzenie i Przełączanie Gałęzi

Utwórz gałąź feature dla systemu powiadomień na podstawie main.
Użyj naszej konwencji nazewnictwa gałęzi.

Claude tworzy gałąź, nazywa ją zgodnie z Twoimi konwencjami (jeśli określone w CLAUDE.md) i przełącza się na nią. Jeśli nie masz udokumentowanej konwencji nazewnictwa, Claude domyślnie używa wzorców takich jak feature/notification-system lub fix/auth-timeout.

Aktualizowanie Gałęzi

Zrebasuj moją gałąź na najnowszy main. Jeśli są konflikty,
pokaż mi każdy i wyjaśnij, co się stało przed rozwiązaniem.

Claude pobiera najnowsze zmiany, rozpoczyna rebase i przeprowadza Cię przez wszelkie konflikty, zamiast rozwiązywać je cicho.

Czyszczenie Gałęzi

Pokaż mi, które lokalne gałęzie zostały już scalone z main
i mogą być bezpiecznie usunięte.

Claude uruchamia polecenia git, aby zidentyfikować scalone gałęzie i przedstawia listę. Zatwierdzasz przed usunięciem czegokolwiek.

Rozwiązywanie Konfliktów Merge

Konflikty merge to miejsce, gdzie Claude dostarcza najwięcej wartości. Zamiast wpatrywać się w znaczniki konfliktów i próbować zrozumieć dwie konkurujące zmiany, otrzymujesz wyjaśnienie w prostym języku.

Prompt do skopiowania i wklejenia do rozwiązywania konfliktów merge:

I have merge conflicts after rebasing on main. For each conflict:

1. Explain what both sides of the conflict are trying to do
2. Identify if either side is clearly correct, or if both need
   to be combined
3. Show me the proposed resolution
4. Wait for my approval before resolving each file

Do not auto-resolve. I want to understand each conflict.

Claude odczytuje znaczniki konfliktów, śledzi historię obu zmian i wyjaśnia sytuację. W przypadku konfliktu w pliku uwierzytelniania Claude może powiedzieć: “Gałąź main dodała rate limiting do handlera logowania. Twoja gałąź zrestrukturyzowała handler na mniejsze funkcje. Obie zmiany muszą zostać zachowane — logika rate limiting musi przejść do Twojej nowej funkcji validateLogin.”

Jest to dramatycznie szybsze niż samodzielne czytanie surowych znaczników konfliktów, szczególnie w plikach, których nie napisałeś.

Tworzenie Pull Requestów

PR Jednym Krokiem

Claude Code ma wbudowaną umiejętność, która commituje, pushuje i otwiera PR jednym krokiem:

/commit-push-pr

Obsługuje to cały przepływ: stagowanie zmian, generowanie wiadomości commita, pushowanie gałęzi i tworzenie PR z automatycznie wygenerowanym opisem na podstawie diffa. Nadal respektuje aktywne reguły uprawnień. Od v2.1.206 automatycznie zezwala na push tylko do skonfigurowanego push remote repozytorium (remote.pushDefault albo jedynego remote); inne remote mogą nadal wywołać monit lub zostać zablokowane.

Kontrolowany Workflow PR

Dla większej kontroli nad każdym krokiem:

Przejrzyj swoje zmiany

Podsumuj wszystkie zmiany na tej gałęzi w porównaniu z main.
Pogrupuj je według obszaru (baza danych, API, UI, testy).

Commituj z opisową wiadomością

Commituj te zmiany. Wiadomość commita powinna wyjaśniać, że
dodaliśmy paginację opartą na kursorze do endpointa search, w tym
migrację bazy danych i zaktualizowane testy.

Pushuj i utwórz PR

Pushuj tę gałąź i utwórz pull request przeciwko main. Opis PR
powinien zawierać:
- Podsumowanie tego, co się zmieniło i dlaczego
- Jak przetestować zmiany
- Wszelkie wymagane kroki migracji

Claude używa gh pr create pod maską. Gdy tworzysz PR w ten sposób, sesja jest automatycznie powiązana z tym pull requestem. Możesz wznowić sesję później za pomocą:

claude --from-pr 142

Jest to przydatne, gdy otrzymasz feedback z review i chcesz kontynuować dokładnie tam, gdzie skończyłeś, z tym samym kontekstem.

Prompt do skopiowania i wklejenia dla produkcyjnego PR:

Create a pull request for this branch. Include:

1. A concise title under 70 characters
2. A summary section with 2-3 bullet points on what changed
3. A testing section describing how to verify the changes
4. A note about any breaking changes or migration steps
5. Link to the related issue if there is one

Push the branch first if it has not been pushed yet.

Równoległy Development z Worktrees

Gdy musisz pracować nad wieloma zadaniami jednocześnie — powiedzmy, implementować funkcjonalność, jednocześnie naprawiając pilny błąd — git worktrees pozwalają mieć oddzielne katalogi robocze dla każdej gałęzi, z własną sesją Claude Code.

Konfigurowanie Worktree

Claude Code sam tworzy worktree i to najkrótsza droga — domyślnie sięgaj po nią:

# Tworzy .claude/worktrees/feature-a/ na gałęzi worktree-feature-a i tam startuje
claude --worktree feature-a

# Forma skrócona oraz odgałęzienie od pull requesta (weź # w cudzysłowy)
claude -w feature-a
claude --worktree "#1234"

Przy wyjściu Claude sprawdza, czy usunięcie worktree coś by skasowało. Czysty i bez nazwy sesji — usuwa worktree i gałąź za ciebie; nazwany albo ze zmianami — najpierw pyta. Kształtują to dwa ustawienia:

.worktreeinclude w katalogu repo, w składni .gitignore, kopiuje pliki z .gitignore (np. .env) do każdego worktree tworzonego przez Claude’a. Bez tego każdy świeży checkout startuje bez lokalnej konfiguracji. Trzymaj tę listę przy tym, co aplikacja potrzebuje, żeby wstać lokalnie: każdy wpis jest duplikowany do każdego worktree, czytelny dla każdego agenta, który tam działa, a uruchomienie z -p zostawia po sobie worktree (i kopie). Prawdziwe sekrety należą do menedżera sekretów, z którego środowisko dev czyta w runtime, a nie do pliku, który rozsyłasz.
worktree.baseRef w ustawieniach ma domyślnie "fresh" (gałąź od domyślnej gałęzi na zdalnym). Ustaw "head", gdy nowy worktree ma nieść twoją niewypchniętą pracę.

Dodaj .claude/worktrees/ do .gitignore, żeby zawartość nie pokazywała się jako pliki nieśledzone w głównym checkoucie.

Po gita sięgaj wprost, gdy potrzebujesz konkretnej istniejącej gałęzi albo worktree poza .claude/worktrees/:

# Nowa gałąź
git worktree add ../myproject-feature-a -b feature/notifications

# Istniejąca gałąź
git worktree add ../myproject-hotfix hotfix/auth-timeout

Każdy worktree to oddzielny katalog z własnym checkoutem. Dzielą tę samą historię git — i ten sam katalog .git, więc git commit działa z wnętrza worktree — ale mają całkowicie izolowane stany plików.

Uruchamianie Claude w Każdym Worktree

Otwórz oddzielne terminale dla każdego worktree:

# Terminal 1: Praca nad funkcjonalnością
cd ../myproject-feature-a
claude

# Terminal 2: Hotfix
cd ../myproject-hotfix
claude

Każda instancja Claude ma własną sesję, własny kontekst i widzi tylko pliki w swoim worktree. Nie ma krzyżowego skażenia między zadaniami.

Czyszczenie Worktrees

Gdy skończysz z worktree:

# Usuń katalog worktree
git worktree remove ../myproject-feature-a

# Lub jeśli gałąź została scalona, wyczyść
git worktree prune

Kontynuowanie Sesji Poprzez Operacje Git

Sesje Claude Code są powiązane z Twoim katalogiem, nie z Twoją gałęzią. Gdy przełączasz gałęzie, Claude nadal widzi historię Twojej konwersacji, ale teraz odczytuje pliki nowej gałęzi. Oznacza to, że możesz:

Rozpocząć sesję na gałęzi feature
Przełączyć się na main, aby coś sprawdzić
Wrócić i kontynuować tam, gdzie skończyłeś

Aby wyraźnie kontynuować swoją ostatnią sesję:

claude -c

Aby wznowić konkretną sesję:

claude --resume

Otwiera to interaktywny selektor sesji. Wyświetlane są sesje z tego samego repozytorium git — w tym wszelkie worktrees — więc możesz wybrać tę, której potrzebujesz. Jeśli znasz ID lub nazwę sesji, możesz wznowić ją bezpośrednio: claude --resume auth-refactor.

Historia Git jako Narzędzie Debugowania

Claude może używać historii git, aby zrozumieć, jak ewoluował kod i śledzić, kiedy wprowadzono błędy:

Kiedy ostatnio zmieniono zachowanie timeout uwierzytelniania?
Pokaż mi commit i diff.

Znajdź commit, który wprowadził regresję w module płatności.
Błąd został zgłoszony 15 stycznia, więc sprawdź commity
z tygodnia przed tym.

Pokaż mi wszystkie zmiany w @src/lib/auth.ts w ostatnim miesiącu.
Podsumuj, co zrobił każdy commit.

Claude uruchamia git log, git blame i git diff, aby śledzić historię. Jest to szczególnie przydatne przy debugowaniu problemów w kodzie, którego nie napisałeś.

Kiedy Workflow Git w Claude Code Się Psuje

Claude commituje pliki, których nie zamierzałeś — Bądź wyraźny co do tego, co stagować. Zamiast “commituj wszystko”, powiedz “commituj tylko pliki w src/api/.” Lub staguj ręcznie za pomocą git add najpierw, a następnie poproś Claude o commitowanie tylko zmian staged.

Wiadomość commita nie pasuje do Twoich konwencji — Dodaj swój format commitów do CLAUDE.md. Claude czyta to przed generowaniem wiadomości. Jeśli format nadal jest zły, powiedz Claude: “Ta wiadomość nie przestrzega naszej konwencji. Przepisz ją jako conventional commit ze scope.”

Rozwiązanie konfliktu merge traci ważne zmiany — Zawsze proś Claude o wyjaśnienie każdego konfliktu przed rozwiązaniem. Sprawdź proponowane rozwiązanie przed zatwierdzeniem. Jeśli Claude się myli, powiedz mu: “To rozwiązanie upuściło logikę rate limiting z main. Zachowaj zarówno rate limiting, jak i moją zrefaktoryzowaną strukturę funkcji.”

Opis PR jest zbyt ogólny — Daj Claude konkretne instrukcje o tym, co uwzględnić. “Utwórz PR” produkuje ogólny opis. “Utwórz PR, który wyjaśnia podejście do paginacji, wymienia nowe endpointy i opisuje krok migracji” produkuje coś użytecznego.

Sesje worktree interferują ze sobą — Do w pełni izolowanej równoległej pracy każde zadanie potrzebuje własnego katalogu worktree. Dwie sesje w tym samym katalogu niczego nie uszkodzą, ale ich logi konwersacji się przeplatają; jeśli potrzebujesz tylko świeżej gałęzi z tego samego punktu startowego, prościej użyć claude --resume <id> --fork-session. Użyj git worktree list, aby zweryfikować, że Twoje worktrees są prawidłowo skonfigurowane.

Co Dalej po Kontroli Wersji

Z workflow kontroli wersji na miejscu dowiedz się, jak obsługiwać błędy z gracją, gdy coś pójdzie nie tak podczas developmentu.

Odzyskiwanie po Błędach Obsługa błędów i odzyskiwanie po pomyłkach

Workflow Developmentu Zbuduj swoją pierwszą funkcjonalność od początku do końca