Slik bruker du Git med en app bygget med KI

For å bruke Git med en KI-bygget app kobler du prosjektet til et Git-repositorium, lagrer (commit) etter hver endring som fungerer, skriver en enlinjes melding om hva som endret seg, og holder hemmeligheter ute med en .gitignore. Bruk en egen gren for alt risikabelt, hent endringer før du prompter igjen hvis noen andre har endret koden, og når KI-en ødelegger noe, gå tilbake til siste fungerende commit i stedet for å prompte videre oppå rotet.

Git er versjonskontroll: en historikk over hver lagret versjon av koden din. GitHub er en nettside som lagrer Git-repositorier på nett. Hvis dette er nytt for deg, start med hva GitHub er. Denne guiden handler om vanene som gjør Git nyttig når en KI skriver mesteparten av koden.

Hvorfor Git betyr mer med KI

En KI kan endre tjue filer i én tur. Det er raskt, men det betyr også at ett prompt stille og rolig kan ødelegge noe du testet i går. Git gir deg:

En vei tilbake. Enhver lagret versjon kan gjenopprettes.
En oversikt over endringene. Du kan se nøyaktig hvilke filer og linjer et prompt berørte.
En kopi utenfor byggeverktøyet. Koden din ligger et sted du kontrollerer.
En standard overlevering. Enhver utvikler, hosting-tjeneste eller ethvert verktøy kan jobbe fra et Git-repositorium.

Steg 1: Koble til et repositorium

Opprett et repositorium (vanligvis privat) på GitHub eller en lignende tjeneste, og koble prosjektet ditt til det. De fleste KI-appbyggere som støtter Git gjør dette fra en innstillingsside med en knapp som heter «Connect GitHub». Hvis din ikke gjør det, kan du eksportere koden og pushe den selv, eller be en utvikler sette det opp én gang.

Før første push må repositoriet ignorere ting som ikke skal være der:

Sjekk .gitignore-filen. Sørg for at den ekskluderer .env-filer, node_modules, mapper med byggeresultater og alle filer med hemmeligheter. Fortell meg hva du la til.

Steg 2: Lagre etter hver endring som fungerer

En commit er et lagret øyeblikksbilde med en melding. Vanen som betyr mest: lagre når noe fungerer, før du ber om neste ting.

Prompt for én endring.
Sjekk den i forhåndsvisningen.
Hvis den fungerer, lagre (commit eller synkroniser) med en melding.
Gå så videre.

Små commits betyr at du, når noe ryker, vet hvilken endring som forårsaket det, og at angring ikke kaster bort annet arbeid.

Steg 3: Skriv meldinger du kan lese senere

En god melding sier hva som endret seg og hvorfor, på én linje:

Bra: Legg til CSV-eksport på ordresiden
Bra: Fiks at bookingskjemaet avviser tidspunkter etter kl. 18
Ikke nyttig: oppdatering, endringer, fikset ting

Du kan be KI-en skrive dem:

Oppsummer endringene siden forrige commit i én linje, som starter med et verb og er under 70 tegn.

Steg 4: Bruk grener til risikabelt arbeid

En gren er en egen arbeidslinje. Du kan prøve noe på en gren, og hvis det ikke går, forkaste det uten å røre hovedversjonen.

Bruk en gren når:

Endringen er stor (en redesign, en ny betalingsflyt, en databaseendring).
Noen andre jobber med den samme appen.
Du vil at noen skal se gjennom endringen før den går live.

Når arbeidet er ferdig og testet, blir det slått sammen (merget) tilbake til hovedgrenen. På GitHub skjer dette vanligvis gjennom en pull request, en side som viser endringene for gjennomgang. Hvis byggeverktøyet ditt bare synkroniserer én gren, kan en utvikler håndtere grenene på GitHub-siden.

Steg 5: Angre trygt

Når et prompt ødelegger appen, må du motstå trangen til å prompte fem ganger til oppå det. Gå tilbake til siste gode versjon og prøv et tydeligere prompt.

I byggeverktøyet: bruk checkpoint- eller gjenopprettingsfunksjonen, hvis den finnes.
I Git: git revert lager en ny commit som angrer en gammel, og beholder historikken. Det er det trygge valget for kode andre kan ha hentet.
Unngå git push --force på en delt gren med mindre du vet nøyaktig hvorfor. Det skriver historikken om for alle.

Hvis du er usikker, spør:

Den siste endringen ødela innloggingssiden. Vis meg hvilke filer den endret sammenlignet med forrige commit, og forklar hva hver endring gjorde. Ikke endre noe ennå.

Steg 6: Hent endringer før du prompter

Hvis en utvikler eller et annet verktøy endrer koden på GitHub, vet ikke KI-byggeren om det før du henter (pull) endringene inn. Å prompte på gammel kode gir konflikter og tapt arbeid.

Hent endringer i starten av hver økt.
Bli enige om hvem som redigerer hva, og unngå at begge sider redigerer de samme filene samtidig.
Hvis du får en sammenslåingskonflikt (to endringer i de samme linjene), be utvikleren eller KI-en løse den og forklare valget.

Eksempelprompter

Før vi starter: hva har endret seg i repositoriet siden forrige økt? Oppsummer commitene.

Gjør neste endring alene: legg til en «Dupliser»-knapp på hver faktura. Ikke endre noe annet, så jeg kan committe den separat.

Sjekk at ingen API-nøkler, passord eller .env-filer er sporet i Git, også i tidligere commits. Rapporter bare filnavn, ikke verdier.

Vanlige feil

Å committe hemmeligheter. Når en nøkkel først er i Git-historikken, er den eksponert, selv etter at du sletter filen. Bytt den ut.
Én stor commit i uken. Du kan ikke angre én endring uten å angre alle.
Meldinger som «oppdatering». Historikken blir ubrukelig når du skal finne hva som ødela noe.
Å prompte på utdatert kode. Hent først når noen andre redigerer.
Force-push for å rette en feil. Det kan slette andres arbeid. Bruk revert i stedet.
Å committe node_modules. Den er enorm og blir uansett gjenskapt fra lock-filen.

Sjekkliste

Prosjektet er koblet til et privat repositorium.
.gitignore ekskluderer .env, node_modules, byggeresultater og hemmeligheter.
Jeg committer etter hver endring som fungerer.
Commit-meldinger sier hva som endret seg, på én linje.
Store eller risikable endringer ligger på en gren og blir gjennomgått.
Jeg henter endringer før jeg prompter når noen andre redigerer koden.
Jeg angrer med checkpoints eller git revert, ikke force-push.
Enhver nøkkel som noen gang er committet, er byttet ut.

Git på Mythex

Mythex lagrer et git-checkpoint etter hver vellykkede agent-tur, og Gå tilbake til dette punktet ruller prosjektet tilbake til det. Det er angringen på byggersiden som beskrives i steg 5. Se Iterer uten å bygge på nytt.

På Pro kobler GitHub-synkronisering et repositorium fra prosjektinnstillingene, slik at du kan pushe og hente mot det, og eksport laster ned prosjektet uten hemmeligheter og node_modules. Se GitHub, eksport og import. Å koble til GitHub før du gir et prosjekt til en utvikler gjør overleveringen mye enklere. Se slik samarbeider du med en utvikler om en KI-bygget app og slik eksporterer og selv-hoster du en KI-bygget app.

Spørsmål

Trenger jeg Git hvis KI-appbyggeren min har checkpoints?

Checkpoints dekker angring mens du bygger. Git legger til en kopi av koden din utenfor byggeverktøyet, en historikk andre kan lese, og en standard måte for en utvikler eller et annet verktøy å jobbe med den samme koden på. Hvis appen er viktig, bruk begge deler.

Hvor ofte bør jeg lagre (commit) når jeg bygger med KI?

Etter hver endring som fungerer, vanligvis etter hvert vellykket prompt eller en liten gruppe prompter. Små commits gjør det enkelt å finne og angre den ene endringen som ødela noe.

Hva skal aldri lagres i Git?

API-nøkler, passord, .env-filer med ekte verdier og mapper med installerte avhengigheter, som node_modules. Legg dem til i .gitignore før første commit, og bytt ut enhver nøkkel som noen gang har blitt committet.

Kan jeg redigere koden på GitHub og fortsette å bygge med KI?

Ja, hvis byggeverktøyet ditt kan hente endringer fra GitHub. Hent endringene før du prompter igjen, slik at KI-en jobber med den nyeste koden, og unngå at begge sider redigerer de samme filene samtidig.