Kontrola Wersji: Integracja Git i Workflow PR

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 Tego Przewodnika

• 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:

1. Uruchomi git diff i git status, aby zobaczyć wszystkie zmiany
2. Przeanalizuje diff, aby zrozumieć intencję
3. Wygeneruje opisową wiadomość commita
4. Pokaże Ci wiadomość do zatwierdzenia
5. 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:

Wskazówka

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

Mam zmiany w wielu plikach. Podziel je na logiczne commity:

1. Spójrz na wszystkie zmiany i pogrupuj je według celu
2. Dla każdej grupy, staguj tylko odpowiednie pliki
3. Napisz wiadomość conventional commit dla każdej grupy
4. Pokaż mi plan przed commitowaniem czegokolwiek

Nie commituj, dopóki nie zatwierdzę grupowania.

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.

Wskazówka

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

Mam konflikty merge po rebase na main. Dla każdego konfliktu:

1. Wyjaśnij, co obie strony konfliktu próbują zrobić
2. Określ, czy któraś strona jest wyraźnie poprawna, czy obie muszą
   być połączone
3. Pokaż mi proponowane rozwiązanie
4. Poczekaj na moje zatwierdzenie przed rozwiązaniem każdego pliku

Nie rozwiązuj automatycznie. Chcę zrozumieć każdy konflikt.

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.

Kontrolowany Workflow PR

Dla większej kontroli nad każdym krokiem:

1. 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).

2. 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.

3. 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.

Wskazówka

Prompt do skopiowania i wklejenia dla produkcyjnego PR:

Utwórz pull request dla tej gałęzi. Uwzględnij:

1. Zwięzły tytuł poniżej 70 znaków
2. Sekcję podsumowania z 2-3 punktami o tym, co się zmieniło
3. Sekcję testowania opisującą, jak zweryfikować zmiany
4. Notatkę o wszelkich breaking changes lub krokach migracji
5. Link do powiązanego issue, jeśli istnieje

Najpierw pushuj gałąź, jeśli nie została jeszcze pushowana.

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łasnymi sesjami Claude Code.

Konfigurowanie Worktree

# Utwórz nowy worktree z nową gałęzią
git worktree add ../myproject-feature-a -b feature/notifications

# Lub z istniejącą gałęzią
git worktree add ../myproject-hotfix hotfix/auth-timeout

Każdy worktree to oddzielny katalog z własnym checkoutem. Dzielą tę samą historię git, 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 scalone, wyczyść
git worktree prune

Notatka

Worktrees to oficjalnie zalecany sposób uruchamiania równoległych sesji Claude Code. Uruchamianie wielu instancji Claude w tym samym katalogu nie jest wspierane i spowoduje konflikty. Każda instancja Claude potrzebuje własnego katalogu roboczego.

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 selektor sesji, w którym możesz filtrować według gałęzi za pomocą klawisza B.

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 To 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ą — Każdy worktree musi być w oddzielnym katalogu. Jeśli przypadkowo uruchomisz dwie instancje Claude w tym samym katalogu, zatrzymaj jedną z nich. Użyj git worktree list, aby zweryfikować, że Twoje worktrees są prawidłowo skonfigurowane.

Co Dalej

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