Git przy pracy z AI: jak nie stracić kontroli nad projektem

Model może napisać: „Poprawiłem walidację formularza i nie zmieniałem innych elementów”. Brzmi dobrze, ale opis nie jest dowodem. Dowodem jest diff, czyli porównanie poprzedniej i obecnej wersji pliku.

- <button type="submit">Wyślij zapytanie</button>
+ <button type="submit">Wyślij</button>

- if (!email || !phone) return showError("Podaj email i telefon");
+ if (!email) return showError("Podaj email");

- exportRow.push(lead.internalNote);
+ // usunięto

Przycisk zmienił tekst. Walidacja telefonu zniknęła. Eksport CSV stracił pole. Opis mówił „poprawka walidacji”. Diff pokazuje pełniejszą prawdę.

AI nie zawsze zmienia rzeczy celowo. Czasem „porządkuje” fragment, który wygląda na zbędny, ale w praktyce wynika z decyzji biznesowej. Bez Gita taki efekt uboczny często wychodzi dopiero wtedy, gdy klient albo zespół zgłosi problem.

Stabilna wersja projektu powinna zostać na głównej gałęzi. Większą zmianę warto robić osobno, na branchu. Dzięki temu AI może przebudowywać komponenty, zmieniać strukturę danych i testować rozwiązania bez ryzyka, że przerwie działający system.

Przykład dla panelu leadów:

git switch -c feature/lead-priority

Na takim branchu można dodać priorytety, statusy, notatki wewnętrzne i zmiany w eksporcie CSV. Dopiero po sprawdzeniu łączy się zmianę ze stabilną wersją.

Przy szybkiej pracy z AI łatwo wpaść w tryb ciągłego poprawiania bez zatrzymania. Po godzinie projekt wygląda inaczej, ale nikt nie wie, które zmiany były świadome, a które są skutkiem ubocznym.

Commit powinien powstawać po działającym etapie. Nie po całym dniu chaotycznych poprawek i nie po serii przypadkowych eksperymentów.

Dodaj pola priorytetu i statusu leadów
Rozszerz eksport CSV o notatkę wewnętrzną
Popraw filtrowanie leadów w panelu admina
Napraw walidację formularza kontaktowego

Taka historia jest czytelna dla człowieka, zespołu i kolejnej sesji z AI. Model dostaje konkretny kontekst zamiast zgadywać, czy zmiany były przypadkowe, testowe, czy gotowe do utrzymania.

Nie każdy projekt wymaga pełnego procesu. Jednorazowy skrypt do uporządkowania pliku, mały formularz bez logiki biznesowej albo notatnikowy prototyp mogą czasem obejść się kopią pliku i zdrowym rozsądkiem.

Git zaczyna mieć sens, gdy projekt:

• jest używany przez więcej niż jedną osobę
• ma wersję produkcyjną i jednocześnie jest rozwijany
• przechowuje logikę procesu biznesowego: eksport, obliczenia, integracje albo statusy
• jest modyfikowany często, szczególnie z pomocą AI
• ma wracać do wcześniejszych decyzji po kilku tygodniach lub miesiącach

Jeśli żaden z tych warunków nie zachodzi, nie ma przymusu. Jeśli choć jeden zachodzi, brak Gita jest świadomym ryzykiem, nie oszczędnością.

Nie trzeba znać całego Gita, żeby zyskać kontrolę nad projektem wspieranym przez AI. W małej firmie wystarczy prosty zestaw zasad.

Dobry rytm pracy nie jest skomplikowany. Najpierw ustalasz zakres. Potem AI robi zmianę. Następnie sprawdzasz diff, uruchamiasz test lub build, poprawiasz błędy i dopiero wtedy commitujesz.

git status
git diff
npm run build
git add src/...
git commit -m "Dodaj kontrolę statusu leadów"

Ten rytm jest nudny, ale skuteczny. Szczególnie tam, gdzie AI może dotknąć kilku plików naraz i wprowadzić zmianę, której nikt nie zauważy podczas samej rozmowy z modelem.

Git nie pomaga tylko człowiekowi. Pomaga też kolejnemu agentowi albo kolejnemu modelowi, który wraca do projektu. Zamiast opisu „coś było poprawiane”, ma historię konkretnych decyzji.

• widać ostatnie commity i ich intencję
• widać, które pliki są jeszcze zmienione
• można oddzielić zmiany robocze od gotowych
• łatwiej znaleźć moment, w którym pojawił się błąd
• da się cofnąć jeden etap bez ręcznego odtwarzania wszystkiego

W praktyce to skraca czas rozmowy z AI. Nie trzeba zaczynać od długiego opisu świata. Wystarczy sprawdzić repozytorium, status i historię zmian.

AI może przyspieszyć rozwój projektu. Może też przyspieszyć jego psucie, jeśli nie ma mechanizmu pozwalającego zobaczyć, cofnąć i zrozumieć każdą zmianę.

Git jest tym mechanizmem. Nie dla porządku, nie dla estetyki i nie dla programistycznego ceremoniału. Dla kontroli nad projektem, który zmienia się szybciej niż jesteś w stanie śledzić bez narzędzi.

Różnica między profesjonalnym wdrożeniem AI a serią eksperymentów zapisanych pod nazwą final_final_naprawione_3 często zaczyna się właśnie tutaj.