Jak używać Gita z aplikacją zbudowaną przez AI

Aby używać Gita z aplikacją zbudowaną przez AI, połącz projekt z repozytorium Git, zapisuj commit po każdej działającej zmianie, pisz jednolinijkowy komunikat opisujący, co się zmieniło, i trzymaj sekrety poza repozytorium za pomocą .gitignore. Do ryzykownych zmian używaj gałęzi, przed kolejnym poleceniem pobierz zmiany, jeśli ktoś inny zmienił kod, a gdy AI coś zepsuje, wróć do ostatniego dobrego commitu zamiast dokładać polecenia na bałagan.

Git to kontrola wersji: historia każdej zapisanej wersji kodu. GitHub to strona internetowa, która przechowuje repozytoria Git w sieci. Jeśli to dla Ciebie nowość, zacznij od czym jest GitHub. Ten przewodnik dotyczy nawyków, dzięki którym Git jest użyteczny, gdy większość kodu pisze AI.

Dlaczego Git jest ważniejszy przy AI

AI potrafi zmienić dwadzieścia plików w jednej turze. To szybkie, ale oznacza też, że jedno polecenie może po cichu zepsuć coś, co wczoraj działało. Git daje Ci:

• Drogę powrotu. Każdą zapisaną wersję można przywrócić.
• Zapis zmian. Widzisz dokładnie, które pliki i linie dotknęło polecenie.
• Kopię poza kreatorem. Twój kod leży tam, gdzie go kontrolujesz.
• Standardowe przekazanie. Każdy programista, hosting lub narzędzie może pracować z repozytorium Git.

Krok 1: Połącz repozytorium

Utwórz repozytorium (zwykle prywatne) na GitHubie lub podobnej usłudze i połącz z nim projekt. Większość kreatorów aplikacji AI obsługujących Git robi to na stronie ustawień, przyciskiem „Connect GitHub”. Jeśli Twój nie ma takiej opcji, możesz wyeksportować kod i wysłać go samodzielnie albo poprosić programistę o jednorazową konfigurację.

Przed pierwszym wysłaniem upewnij się, że repozytorium ignoruje rzeczy, które nie powinny się w nim znaleźć:

Sprawdź plik .gitignore. Upewnij się, że wyklucza pliki .env, node_modules, foldery z wynikiem kompilacji i wszystkie pliki zawierające sekrety. Powiedz mi, co dodałeś.

Krok 2: Zapisuj commit po każdej działającej zmianie

Commit to zapisany migawkowo stan kodu z komunikatem. Nawyk, który ma znaczenie: zapisz zmianę, gdy coś działa, zanim poprosisz o następną.

1. Poproś o jedną zmianę.
2. Sprawdź ją w podglądzie.
3. Jeśli działa, wykonaj commit (lub synchronizację) z komunikatem.
4. Dopiero potem przejdź dalej.

Małe commity oznaczają, że gdy coś się zepsuje, wiesz, która zmiana to spowodowała, a jej cofnięcie nie kasuje pozostałej pracy.

Krok 3: Pisz komunikaty, które da się przeczytać później

Dobry komunikat mówi, co się zmieniło i dlaczego, w jednej linijce:

• Dobrze: Dodaj eksport CSV na stronie zamówień
• Dobrze: Napraw formularz rezerwacji, który odrzucał godziny po 18:00
• Bezużyteczne: update, zmiany, napraw różne rzeczy

Możesz poprosić AI, żeby je napisało:

Podsumuj zmiany od ostatniego commitu w jednej linijce, zaczynając od czasownika, do 70 znaków.

Krok 4: Używaj gałęzi przy ryzykownej pracy

Gałąź to osobny nurt pracy. Możesz coś wypróbować na gałęzi i jeśli się nie sprawdzi, porzucić ją bez ruszania wersji głównej.

Użyj gałęzi, gdy:

• Zmiana jest duża (przeprojektowanie, nowy przepływ płatności, zmiana bazy danych).
• Nad tą samą aplikacją pracuje ktoś jeszcze.
• Chcesz, żeby ktoś zrecenzował zmianę, zanim trafi na produkcję.

Gdy praca jest gotowa i przetestowana, zostaje scalona (merge) z główną gałęzią. Na GitHubie zwykle dzieje się to przez pull request, czyli stronę z zestawieniem zmian do przeglądu. Jeśli Twój kreator synchronizuje tylko jedną gałąź, zarządzaniem gałęziami po stronie GitHuba może zająć się programista.

Krok 5: Cofaj bezpiecznie

Gdy polecenie zepsuje aplikację, nie kuś się, żeby wysłać jeszcze pięć poleceń na to wszystko. Wróć do ostatniej dobrej wersji i spróbuj jaśniejszego polecenia.

• W kreatorze: użyj jego punktu kontrolnego lub funkcji przywracania, jeśli istnieje.
• W Gicie: git revert tworzy nowy commit, który cofa stary, zachowując historię. To bezpieczny wybór dla kodu, który inni mogli już pobrać.
• Unikaj git push --force na wspólnej gałęzi, chyba że dokładnie wiesz, po co. Przepisuje historię dla wszystkich.

Jeśli nie masz pewności, zapytaj:

Ostatnia zmiana zepsuła stronę logowania. Pokaż, które pliki zmieniła w porównaniu z poprzednim commitem i wyjaśnij, co zrobiła każda zmiana. Na razie niczego nie zmieniaj.

Krok 6: Pobierz zmiany, zanim poprosisz o kolejne

Jeśli programista lub inne narzędzie zmieni kod na GitHubie, kreator AI nie wie o tym, dopóki nie pobierzesz tych zmian (pull). Polecenia wydawane na starym kodzie prowadzą do konfliktów i utraty pracy.

• Pobieraj zmiany na początku każdej sesji.
• Ustalcie, kto za co odpowiada, i unikajcie edytowania tych samych plików w tym samym czasie.
• Jeśli pojawi się konflikt scalania (dwie zmiany tych samych linii), poproś programistę lub AI o rozwiązanie go i wyjaśnienie wyboru.

Przykładowe polecenia

Zanim zaczniemy: co zmieniło się w repozytorium od mojej ostatniej sesji? Podsumuj commity.

Zrób kolejną zmianę osobno: dodaj przycisk „Duplikuj” do każdej faktury. Nie zmieniaj niczego więcej, żebym mógł zapisać ją osobnym commitem.

Sprawdź, czy w Gicie nie są śledzone żadne klucze API, hasła ani pliki .env, także w poprzednich commitach. Podaj tylko nazwy plików, bez wartości.

Typowe błędy

• Zapisywanie sekretów. Gdy klucz trafi do historii Gita, jest wystawiony, nawet po usunięciu pliku. Wymień go.
• Jeden wielki commit na tydzień. Nie da się cofnąć jednej zmiany bez cofnięcia wszystkich.
• Komunikaty w stylu „update”. Historia przestaje pomagać w znajdowaniu tego, co się zepsuło.
• Polecenia na nieaktualnym kodzie. Gdy ktoś inny edytuje projekt, najpierw pobierz zmiany.
• Wymuszanie wysłania, by naprawić błąd. Może wymazać cudzą pracę. Zamiast tego użyj revert.
• Zapisywanie node_modules. Jest ogromny, a i tak odtwarzany z pliku blokady.

Lista kontrolna

• Projekt jest połączony z prywatnym repozytorium.
• .gitignore wyklucza .env, node_modules, wynik kompilacji i sekrety.
• Zapisuję commit po każdej działającej zmianie.
• Komunikaty commitów opisują zmianę w jednej linijce.
• Duże lub ryzykowne zmiany idą na gałąź i są recenzowane.
• Pobieram zmiany przed poleceniem, gdy ktoś inny edytuje kod.
• Cofam zmiany punktami kontrolnymi lub git revert, nie wymuszonym wysłaniem.
• Każdy klucz, który kiedykolwiek trafił do commitu, został wymieniony.

Git w Mythex

Mythex zapisuje punkt kontrolny Gita po każdej udanej turze agenta, a Przywróć do tego punktu cofa projekt do niego. To cofanie po stronie kreatora, opisane w kroku 5. Zobacz Iterowanie bez przebudowy.

W planie Pro synchronizacja z GitHubem łączy repozytorium z ustawień projektu, dzięki czemu możesz wysyłać i pobierać zmiany, a eksport pobiera projekt bez sekretów i folderu node_modules. Zobacz GitHub, eksport i import. Połączenie GitHuba przed przekazaniem projektu programiście bardzo upraszcza sprawę. Zobacz jak pracować z programistą nad aplikacją zbudowaną przez AI oraz jak wyeksportować i uruchomić aplikację AI na własnym serwerze.

Pytania