Så använder du Git med en app byggd med AI

För att använda Git med en AI-byggd app kopplar du projektet till ett Git-förråd, committar efter varje fungerande ändring, skriver ett meddelande på en rad som beskriver vad som ändrats och håller hemligheter borta med en .gitignore. Använd en branch för allt riskabelt, pulla innan du skriver nästa prompt om någon annan ändrat koden, och när AI:n förstör något, gå tillbaka till den senaste fungerande committen i stället för att prompta ovanpå röran.

Git är versionshantering: en historik över varje sparad version av din kod. GitHub är en webbplats som lagrar Git-förråd online. Om de är nya för dig, börja med vad GitHub är. Den här guiden handlar om vanorna som gör Git användbart när en AI skriver största delen av koden.

Varför Git betyder mer med AI

En AI kan ändra tjugo filer i en och samma tur. Det är snabbt, men det betyder också att en prompt tyst kan förstöra något du testade igår. Git ger dig:

Ett sätt tillbaka. Vilken committad version som helst kan återställas.
En logg över vad som ändrats. Du kan se exakt vilka filer och rader en prompt rörde.
En kopia utanför byggverktyget. Din kod finns någonstans du kontrollerar.
En standardöverlämning. Alla utvecklare, värdtjänster eller verktyg kan arbeta från ett Git-förråd.

Steg 1: Koppla ett förråd

Skapa ett förråd (oftast privat) på GitHub eller en liknande tjänst, och koppla ditt projekt till det. De flesta AI-appbyggare som stödjer Git gör detta via en inställningssida med en knapp "Connect GitHub". Om din inte gör det kan du exportera koden och pusha den själv, eller be en utvecklare ställa in det en gång.

Innan första pushen, se till att förrådet ignorerar sådant som inte ska vara där:

Kontrollera filen .gitignore. Se till att den utesluter .env-filer, node_modules, byggmappar och alla filer som innehåller hemligheter. Berätta vad du lagt till.

Steg 2: Committa efter varje fungerande ändring

En commit är en sparad ögonblicksbild med ett meddelande. Vanan som spelar roll: committa när något fungerar, innan du frågar efter nästa sak.

Be om en ändring.
Kontrollera den i förhandsvisningen.
Om den fungerar, committa (eller synka) med ett meddelande.
Gå sedan vidare.

Små commits gör att du, när något går sönder, vet vilken ändring som orsakade det, och att ångra den inte kastar bort annat arbete.

Steg 3: Skriv meddelanden du kan läsa senare

Ett bra meddelande säger vad som ändrats och varför, på en rad:

Bra: Lägg till CSV-export på ordersidan
Bra: Fixa bokningsformuläret som avvisar tider efter kl. 18
Inte användbart: uppdatering, ändringar, fixar grejer

Du kan be AI:n skriva dem:

Sammanfatta ändringarna sedan senaste committen i en rad, börja med ett verb, under 70 tecken.

Steg 4: Använd branches för riskabelt arbete

En branch är en separat arbetslinje. Du kan prova något på en branch, och om det inte fungerar, överge den utan att röra huvudversionen.

Använd en branch när:

Ändringen är stor (en omdesign, ett nytt betalflöde, en databasändring).
Någon annan arbetar med samma app.
Du vill att någon ska granska ändringen innan den går live.

När arbetet är klart och testat slås det samman tillbaka till huvudbranchen. På GitHub sker det oftast via en pull request, en sida som visar ändringarna för granskning. Om din byggare bara synkar en branch kan en utvecklare hantera branches på GitHub-sidan.

Steg 5: Ångra säkert

När en prompt förstör appen, motstå frestelsen att prompta fem gånger till ovanpå det. Gå tillbaka till den senaste fungerande versionen och prova en tydligare prompt.

I byggaren: använd dess checkpoint- eller återställningsfunktion, om den har en.
I Git: git revert skapar en ny commit som ångrar en gammal och bevarar historiken. Det är det säkra valet för kod som andra kan ha pulled.
Undvik git push --force på en delad branch om du inte vet exakt varför. Det skriver om historiken för alla.

Om du är osäker, fråga:

Den senaste ändringen förstörde inloggningssidan. Visa vilka filer den ändrade jämfört med föregående commit, och förklara vad varje ändring gjorde. Ändra inget ännu.

Steg 6: Pulla innan du prompter

Om en utvecklare eller ett annat verktyg ändrar koden på GitHub vet inte AI-byggaren det förrän du pullar in ändringarna. Att prompta på gammal kod orsakar konflikter och förlorat arbete.

Pulla i början av varje session.
Kom överens om vem som redigerar vad, och undvik att båda sidor redigerar samma filer samtidigt.
Om du får en merge-konflikt (två ändringar av samma rader), be utvecklaren eller AI:n att lösa den och förklara valet.

Exempelprompter

Innan vi börjar: vad ändrades i förrådet sedan min senaste session? Sammanfatta committarna.

Gör nästa ändring på egen hand: lägg till en knapp "Duplicera" vid varje faktura. Ändra inget annat, så att jag kan committa den separat.

Kontrollera att inga API-nycklar, lösenord eller .env-filer spåras i Git, även i tidigare commits. Rapportera endast filnamn, inte värden.

Vanliga misstag

Committa hemligheter. När en nyckel väl finns i Git-historiken är den exponerad, även efter att du tagit bort filen. Byt ut den.
En jättestor commit i veckan. Du kan inte ångra en ändring utan att ångra alla.
Meddelanden som "uppdatering". Historiken blir värdelös för att hitta vad som gick sönder.
Prompta på inaktuell kod. Pulla först när någon annan redigerar.
Force-pusha för att rätta ett misstag. Det kan radera andras arbete. Revertera i stället.
Committa node_modules. Den är enorm och återskapas ändå från låsfilen.

Checklista

Projektet är kopplat till ett privat förråd.
.gitignore utesluter .env, node_modules, byggmappar och hemligheter.
Jag committar efter varje fungerande ändring.
Committmeddelanden säger vad som ändrats på en rad.
Stora eller riskabla ändringar går på en branch och granskas.
Jag pullar innan jag prompter när någon annan redigerar koden.
Jag ångrar med checkpoints eller git revert, inte force-push.
Alla nycklar som någonsin committats har bytts ut.

Git på Mythex

Mythex sparar en git-checkpoint efter varje lyckad agenttur, och Återgå till den här punkten rullar tillbaka projektet till den — den byggarsidiga ångringen från steg 5. Se Iterera utan att bygga om.

På Pro kopplar GitHub-synk ett förråd från projektinställningarna, så att du kan pusha och pulla mot det, och export laddar ner projektet med hemligheter och node_modules borttagna. Se GitHub, export och import. Att koppla GitHub innan du överlämnar ett projekt till en utvecklare gör överlämningen mycket enklare. Se hur du arbetar med en utvecklare på en AI-byggd app och hur du exporterar och self-hostar en AI-byggd app.

Frågor

Behöver jag Git om min AI-appbyggare har checkpoints?

Checkpoints täcker ångra medan du bygger. Git lägger till en kopia av din kod utanför byggverktyget, en historik som andra kan läsa och ett standardsätt för en utvecklare eller ett annat verktyg att arbeta med samma kod. Om appen är viktig, använd båda.

Hur ofta ska jag committa när jag bygger med AI?

Efter varje ändring som fungerar — oftast efter varje lyckad prompt eller en liten grupp prompter. Små commits gör det enkelt att hitta och ångra den enda ändring som gick sönder något.

Vad ska aldrig committas till Git?

API-nycklar, lösenord, .env-filer med riktiga värden och installerade beroendemappar som node_modules. Lägg till dem i .gitignore innan din första commit, och byt ut alla nycklar som någonsin committats.

Kan jag redigera koden på GitHub och fortsätta bygga med AI?

Ja, om din byggare kan hämta ändringar från GitHub. Pulla innan du skriver nästa prompt, så att AI:n arbetar med den senaste koden, och undvik att båda sidor redigerar samma filer samtidigt.