Blog JSystems - uwalniamy wiedzę!

Szukaj

Claude Code

Claude Code nie widzi zmian w repo - staged vs unstaged

W skrócie

  • Prosisz Claude Code o pracę na Twoich zmianach w repozytorium, a narzędzie twierdzi, że ich nie widzi albo bierze pod uwagę nie te, o które chodzi.
  • Claude Code czyta stan repozytorium tak jak git - rozróżnia zmiany dodane do poczekalni (staged) i te jeszcze poza nią (unstaged) - więc jeśli patrzy tylko na jedną grupę, drugiej nie zobaczy.
  • Rozwiązanie: uświadom sobie, w której grupie są Twoje zmiany, poproś narzędzie wprost o właściwy zakres i pilnuj, żeby pliki nie były niezapisane ani ignorowane.

Claude Code, narzędzie CLI od Anthropic do programowania z AI, świetnie współpracuje z gitem - potrafi obejrzeć Twoje zmiany, streścić je, przygotować commit. Robi to jednak tak, jak zrobiłby doświadczony programista: patrząc na stan repozytorium przez komendy gita. A git nie traktuje wszystkich zmian jednakowo. Część siedzi w poczekalni (obszarze staged, przygotowanym do commita), a część jest poza nią (unstaged). Jeśli nie wiesz, gdzie są Twoje zmiany i o co dokładnie prosisz, łatwo o wrażenie, że narzędzie ich nie widzi.

Jak to wygląda w praktyce

Modyfikujesz plik, prosisz Claude Code o przejrzenie zmian, a ono odpowiada, że nie ma żadnych - albo pokazuje tylko część tego, co zrobiłeś. Bywa odwrotnie: wykonałeś git add, a narzędzie i tak mówi o innych plikach niż te przygotowane do commita. Częsty scenariusz to prośba o commit: narzędzie commituje mniej, niż się spodziewałeś, bo część zmian nadal jest poza poczekalnią. Albo zupełnie nie widzi świeżo utworzonego pliku, który leży w katalogu, ale nie został jeszcze dodany do gita. Wygląda to na ślepotę narzędzia, a jest po prostu innym zakresem, na który patrzy.

Dlaczego Claude Code tak działa

Claude Code nie ma magicznego wglądu w Twoje pliki - stan zmian ustala tak samo jak Ty w terminalu, uruchamiając komendy gita w rodzaju git status i git diff. A git rozdziela zmiany na dwie grupy. W poczekalni (staged) są pliki po git add, gotowe do zapisania w commicie - te pokazuje git diff --staged. Poza poczekalnią (unstaged) są zmiany w plikach już śledzonych, których jeszcze nie dodałeś - te pokazuje samo git diff. Oddzielnie istnieją pliki nieśledzone (nowe, o których git jeszcze nie wie, dopóki ich nie dodasz). Dlatego wszystko zależy od tego, o co poprosisz: pytanie o zmiany do commita dotyczy poczekalni, a pytanie o niezapisane zmiany - grupy poza nią. Do tego dochodzą dwie prozaiczne pułapki: zmiana nie została zapisana na dysk w edytorze (więc git jej nie widzi), albo plik jest wykluczony w .gitignore (więc git celowo go pomija).

Jak to rozwiązać krok po kroku

  1. Najpierw ustal, gdzie są Twoje zmiany. Uruchom git status - pokaże, które pliki są w poczekalni (przygotowane do commita), które poza nią, a które są nieśledzone.
  2. Upewnij się, że pliki są zapisane na dysk. Niezapisany bufor edytora nie istnieje dla gita ani dla Claude Code, więc zapisz zmiany, zanim poprosisz o ich przejrzenie.
  3. Poproś narzędzie wprost o właściwy zakres. Jeśli chcesz omówić to, co przygotowane do commita, powiedz o zmianach w poczekalni; jeśli wszystko, co zmienione - poproś o zmiany zarówno w poczekalni, jak i poza nią.
  4. Gdy zależy Ci, by narzędzie widziało komplet, dodaj zmiany do poczekalni komendą git add (a nowe pliki również), po czym poproś o przejrzenie stanu przygotowanego do commita.
  5. Sprawdź, czy pliku nie wyklucza .gitignore. Jeśli git celowo go pomija, ani git status, ani Claude Code go nie pokażą - a to bywa zamierzone.
  6. Przy prośbie o commit doprecyzuj, co ma w nim być. Jasne wskazanie zakresu (tylko poczekalnia czy wszystko) usuwa nieporozumienie, przez które narzędzie commitowało mniej, niż chciałeś.

Jak sprawdzić, że zadziałało

Porównaj to, co mówi Claude Code, z wynikiem git status - narzędzie powinno wskazywać dokładnie te pliki, które git wymienia w danej grupie. Jeśli chodziło o poczekalnię, zestaw odpowiedź z git diff --staged; jeśli o zmiany poza nią - z samym git diff. Po commicie uruchom git status ponownie: poczekalnia powinna być pusta, a w git log powinien pojawić się nowy commit obejmujący właśnie te zmiany, o które prosiłeś. Gdy narzędzie nadal czegoś nie widzi, wróć do dwóch podstaw - czy plik jest zapisany na dysk i czy nie jest wykluczony w .gitignore. To najczęstsze przyczyny pozornej ślepoty.

Wróć do listy: 100 najczęstszych problemów z Claude Code

Szkolenie Claude Code - od zera do zespołu agentów AI, prowadzi Łukasz Matuszewski (JSystems)

Szkolenie Claude Code - od zera do zespołu agentów AI -->

Szkolenie Claude Code - od zera do zespołu agentów AI

Tryb planowania, tryby uprawnień, komendy, MCP, hooki i systemy multi-agent - wszystko na żywym kodzie podczas trzydniowego szkolenia. Prowadzi Łukasz Matuszewski. Szkolenie ma terminy gwarantowane - odbędzie się niezależnie od liczby zgłoszeń.

Sprawdź szkolenie Claude Code

To szkolenie może być dofinansowane dla Ciebie z KFS lub BUR.

★★★★★Średnia ocena naszych szkoleń w Google: 5/5

Najczęściej zadawane pytania

Dlaczego Claude Code twierdzi, że nie widzi moich zmian w repozytorium?
Claude Code ustala stan zmian tak samo jak Ty w terminalu, uruchamiając komendy gita, a git rozdziela zmiany na te dodane do poczekalni i te poza nią. Jeśli patrzy tylko na jedną grupę albo Twoja zmiana jest w drugiej, narzędzie jej nie pokaże, choć nie jest to żadna ślepota.
Czemu narzędzie przy commicie bierze mniej zmian, niż się spodziewam?
Do commita trafiają zmiany z poczekalni, czyli te po git add, a te poza nią zostają pominięte. Jeśli część plików nadal jest poza poczekalnią albo to nowe, nieśledzone pliki, narzędzie ich nie uwzględni, dopóki ich nie dodasz.
Jak sprawić, żeby Claude Code widział właściwe zmiany w repozytorium?
Najpierw uruchom git status, żeby ustalić, które pliki są w poczekalni, poza nią i nieśledzone, i upewnij się, że wszystko jest zapisane na dysk. Potem poproś narzędzie wprost o właściwy zakres, a gdy zależy Ci na komplecie, dodaj zmiany komendą git add i sprawdź, czy pliku nie wyklucza .gitignore.
Jak sprawdzić, że narzędzie objęło dokładnie te zmiany, o które prosiłem?
Porównaj to, co mówi Claude Code, z wynikiem git status i odpowiednim git diff: dla poczekalni z git diff dwa myślniki staged, dla reszty z samym git diff. Po commicie uruchom git status ponownie, poczekalnia powinna być pusta, a w git log powinien pojawić się nowy commit obejmujący właśnie te zmiany.

Komentarze (0)

Musisz być zalogowany by móc dodać komentarz. Zaloguj się przez Google

Brak komentarzy...