Sådan bruger du Git med en app bygget med AI

For at bruge Git med en app bygget med AI, forbinder du projektet til et Git-repository, laver en commit efter hver ændring der virker, skriver en besked på én linje om hvad der er ændret, og holder hemmeligheder ude med en .gitignore. Brug en branch til alt risikabelt, tag et pull, før du prompter igen, hvis en anden har ændret koden, og når AI'en ødelægger noget, så gå tilbage til den sidste gode commit i stedet for at prompte oven på rodet.

Git er versionsstyring: en historik over hver gemt version af din kode. GitHub er en hjemmeside, der gemmer Git-repositories online. Hvis begreberne er nye, så start med hvad GitHub er. Denne guide handler om de vaner, der gør Git nyttigt, når en AI skriver det meste af koden.

Hvorfor Git betyder mere med AI

En AI kan ændre tyve filer på én tur. Det er hurtigt, men det betyder også, at én prompt stille og roligt kan ødelægge noget, du testede i går. Git giver dig:

• En vej tilbage. Enhver committet version kan genoprettes.
• En registrering af hvad der er ændret. Du kan se præcis hvilke filer og linjer en prompt rørte.
• En kopi uden for byggeværktøjet. Din kode ligger et sted, du kontrollerer.
• Et standard-håndoff. Enhver udvikler, host eller værktøj kan arbejde ud fra et Git-repository.

Trin 1: Forbind et repository

Opret et repository (normalt privat) på GitHub eller en lignende tjeneste, og forbind dit projekt til det. De fleste AI-appbyggere, der understøtter Git, gør det via en indstillingsside med en knap til „Connect GitHub“. Hvis din ikke gør, kan du eksportere koden og skubbe den selv, eller bede en udvikler om at sætte det op én gang.

Før den første push skal du sikre, at repositoryet ignorerer ting, der ikke skal med:

Tjek .gitignore-filen. Sørg for at den udelukker .env-filer, node_modules, mapper med build-output og alle filer med hemmeligheder. Fortæl mig hvad du har tilføjet.

Trin 2: Lav en commit efter hver ændring der virker

En commit er et gemt øjebliksbillede med en besked. Vanen der betyder mest: lav en commit, når noget virker, før du beder om den næste ting.

1. Prompt for én ændring.
2. Tjek den i forhåndsvisningen.
3. Hvis den virker, så lav en commit (eller synkronisér) med en besked.
4. Gå så videre.

Små commits betyder, at du ved hvilken ændring der ødelagde noget, og at det at fortryde den ikke smider andet arbejde væk.

Trin 3: Skriv beskeder, du kan læse senere

En god besked siger hvad der er ændret og hvorfor, på én linje:

• Godt: Tilføj CSV-eksport til ordresiden
• Godt: Ret bookingformularen, der afviser tidspunkter efter kl. 18
• Ikke nyttigt: opdatering, ændringer, ret ting

Du kan bede AI'en skrive dem:

Opsummer ændringerne siden sidste commit i én linje, startende med et verbum, under 70 tegn.

Trin 4: Brug branches til risikabelt arbejde

En branch er en separat arbejdslinje. Du kan prøve noget på en branch, og hvis det ikke går, så opgiver du det uden at røre hovedversionen.

Brug en branch når:

• Ændringen er stor (et redesign, et nyt betalingsflow, en databaseændring).
• En anden arbejder på den samme app.
• Du vil have at nogen gennemgår ændringen, før den går live.

Når arbejdet er færdigt og testet, bliver det merged tilbage i hovedbranchen. På GitHub sker det normalt gennem en pull request, en side der viser ændringerne til gennemgang. Hvis din byggeværktøj kun synkroniserer én branch, kan en udvikler håndtere branches på GitHub-siden.

Trin 5: Fortryd sikkert

Når en prompt ødelægger appen, så modstå trangen til at prompte fem gange mere oven på den. Gå tilbage til den sidste gode version og prøv en tydeligere prompt.

• I byggeværktøjet: brug dets checkpoint- eller gendannelsesfunktion, hvis den findes.
• I Git: git revert laver en ny commit, der fortryder en gammel, og bevarer historikken. Det er det sikre valg for kode, andre kan have hentet.
• Undgå git push --force på en delt branch, medmindre du præcis ved hvorfor. Det omskriver historikken for alle.

Hvis du er i tvivl, så spørg:

Den sidste ændring ødelagde login-siden. Vis mig hvilke filer den ændrede sammenlignet med den forrige commit, og forklar hvad hver ændring gjorde. Ændr ikke noget endnu.

Trin 6: Tag et pull, før du prompter

Hvis en udvikler eller et andet værktøj ændrer koden på GitHub, ved AI-byggeværktøjet ikke det, før du henter de ændringer ind. At prompte på gammel kode fører til konflikter og tabt arbejde.

• Tag et pull i starten af hver session.
• Aftal hvem der redigerer hvad, og undgå at begge sider redigerer de samme filer på samme tid.
• Hvis du får en merge-konflikt (to ændringer af de samme linjer), så bed udvikleren eller AI'en om at løse den og forklare valget.

Eksempelprompts

Før vi starter: hvad er ændret i repositoryet siden min sidste session? Opsummer commits.

Lav den næste ændring alene: tilføj en „Dupliker“-knap til hver faktura. Ændr ikke andet, så jeg kan committe den separat.

Tjek at ingen API-nøgler, adgangskoder eller .env-filer er sporet i Git, også i tidligere commits. Rapportér kun filnavne, ikke værdier.

Almindelige fejl

• At committe hemmeligheder. Når en nøgle først er i Git-historikken, er den eksponeret, selv efter du sletter filen. Skift den.
• Én stor commit om ugen. Du kan ikke fortryde én ændring uden at fortryde dem alle.
• Beskeder som „opdatering“. Historikken bliver ubrugelig til at finde hvad der gik i stykker.
• At prompte på forældet kode. Tag et pull først, når en anden redigerer.
• At force-pushe for at rette en fejl. Det kan slette andres arbejde. Brug revert i stedet.
• At committe node_modules. Den er enorm og genskabes alligevel ud fra lock-filen.

Tjekliste

• Projektet er forbundet til et privat repository.
• .gitignore udelukker .env, node_modules, build-output og hemmeligheder.
• Jeg laver en commit efter hver ændring der virker.
• Commit-beskeder siger hvad der er ændret på én linje.
• Store eller risikable ændringer går på en branch og gennemgås.
• Jeg tager et pull før jeg prompter, når en anden redigerer koden.
• Jeg fortryder med checkpoints eller git revert, ikke force-push.
• Enhver nøgle der nogensinde er committet, er skiftet.

Git på Mythex

Mythex gemmer et git-checkpoint efter hver vellykket agent-tur, og Gå tilbage til dette punkt ruller projektet tilbage til det — den byggeside-fortrydelse der er beskrevet i trin 5. Se Iterér uden at bygge forfra.

På Pro forbinder GitHub-synkronisering et repository fra projektindstillingerne, så du kan pushe og pulle mod det, og eksport downloader projektet med hemmeligheder og node_modules udeladt. Se GitHub, eksport og import. At forbinde GitHub, før du giver et projekt til en udvikler, gør overdragelsen meget enklere — se sådan arbejder du med en udvikler på en app bygget med AI og sådan eksporterer og self-hoster du en app bygget med AI.

Spørgsmål