Git gebruiken met een met AI gebouwde app

Om Git met een met AI gebouwde app te gebruiken, koppel je het project aan een Git-repository, commit je na elke wijziging die werkt, schrijf je per commit één regel over wat er veranderde en houd je geheimen buiten de repository met een .gitignore. Gebruik een branch voor alles wat riskant is, pull voordat je opnieuw een prompt geeft als iemand anders de code heeft gewijzigd, en als de AI iets breekt, ga je terug naar de laatste goede commit in plaats van er bovenop nog meer prompts te sturen.

Git is versiebeheer: een geschiedenis van elke opgeslagen versie van je code. GitHub is een website die Git-repositories online bewaart. Als deze begrippen nieuw voor je zijn, begin dan met wat GitHub is. Deze gids gaat over de gewoonten die Git nuttig maken wanneer een AI het grootste deel van de code schrijft.

Waarom Git belangrijker is met AI

Een AI kan in één beurt twintig bestanden wijzigen. Dat is snel, maar het betekent ook dat één prompt stilletjes iets kan breken dat je gisteren nog hebt getest. Git geeft je:

• Een manier terug. Elke vastgelegde versie kan worden hersteld.
• Een overzicht van wat er veranderde. Je ziet precies welke bestanden en regels een prompt heeft geraakt.
• Een kopie buiten de builder. Je code staat ergens waar jij de controle over hebt.
• Een standaard overdracht. Elke developer, host of tool kan vanuit een Git-repository werken.

Stap 1: koppel een repository

Maak een repository aan (meestal privé) op GitHub of een vergelijkbare dienst, en koppel je project eraan. De meeste AI-app-builders die Git ondersteunen doen dit via een instellingenpagina met een knop ‘Connect GitHub’. Als jouw builder dat niet heeft, kun je de code exporteren en zelf pushen, of een developer eenmalig laten instellen.

Zorg voordat je de eerste push doet dat de repository dingen negeert die er niet in horen:

Controleer het .gitignore-bestand. Zorg dat het .env-bestanden, node_modules, build-uitvoermappen en elk bestand met geheimen uitsluit. Vertel me wat je hebt toegevoegd.

Stap 2: commit na elke werkende wijziging

Een commit is een opgeslagen momentopname met een bericht. De gewoonte die telt: commit wanneer iets werkt, voordat je om het volgende vraagt.

1. Vraag om één wijziging.
2. Controleer die in de preview.
3. Als het werkt, commit je (of synchroniseer je) met een bericht.
4. Ga dan verder.

Kleine commits betekenen dat je, als er iets breekt, weet welke wijziging het veroorzaakte, en dat ongedaan maken het andere werk niet weggooit.

Stap 3: schrijf berichten die je later kunt lezen

Een goed bericht zegt in één regel wat er veranderde en waarom:

• Goed: Voeg CSV-export toe aan de orderpagina
• Goed: Los op dat het boekingsformulier tijden na 18:00 afwijst
• Niet nuttig: update, wijzigingen, dingen gefixt

Je kunt de AI vragen ze te schrijven:

Vat de wijzigingen sinds de laatste commit samen in één regel, beginnend met een werkwoord, en korter dan 70 tekens.

Stap 4: gebruik branches voor riskant werk

Een branch is een aparte lijn van werk. Je kunt iets op een branch proberen, en als het niet uitpakt, laat je die los zonder de hoofdversie aan te raken.

Gebruik een branch wanneer:

• De wijziging groot is (een herontwerp, een nieuwe betaalstroom, een databasewijziging).
• Iemand anders aan dezelfde app werkt.
• Je wilt dat iemand de wijziging controleert voordat die live gaat.

Als het werk klaar en getest is, wordt het gemerged terug in de hoofdbranch. Op GitHub gebeurt dat meestal via een pull request, een pagina met de wijzigingen ter beoordeling. Als jouw builder maar één branch synchroniseert, kan een developer de branches aan de GitHub-kant beheren.

Stap 5: herstel veilig

Als een prompt de app breekt, weersta dan de drang om vijf keer opnieuw te prompten bovenop de rommel. Ga terug naar de laatste goede versie en probeer een duidelijkere prompt.

• In de builder: gebruik de checkpoint- of herstelfunctie, als die er is.
• In Git: git revert maakt een nieuwe commit die een oude ongedaan maakt, waardoor de geschiedenis intact blijft. Dat is de veilige keuze voor code die anderen misschien al hebben opgehaald.
• Vermijd git push --force op een gedeelde branch, tenzij je precies weet waarom. Het herschrijft de geschiedenis voor iedereen.

Weet je het niet zeker, vraag dan:

De laatste wijziging heeft de inlogpagina gebroken. Laat me zien welke bestanden zijn gewijzigd ten opzichte van de vorige commit, en leg uit wat elke wijziging deed. Verander nog niets.

Stap 6: pull voordat je een prompt geeft

Als een developer of een ander hulpmiddel de code op GitHub wijzigt, weet de AI-builder dat niet totdat jij die wijzigingen pulled. Prompten op oude code leidt tot conflicten en verloren werk.

• Pull aan het begin van elke sessie.
• Spreek af wie wat bewerkt, en voorkom dat beide kanten tegelijk dezelfde bestanden aanpassen.
• Als je een merge-conflict krijgt (twee wijzigingen aan dezelfde regels), vraag dan de developer of de AI om het op te lossen en de keuze uit te leggen.

Voorbeeldprompts

Voordat we beginnen: wat is er sinds mijn laatste sessie veranderd in de repository? Vat de commits samen.

Doe de volgende wijziging op zichzelf: voeg een knop ‘Dupliceren’ toe aan elke factuur. Verander verder niets, zodat ik die apart kan committen.

Controleer dat er geen API-sleutels, wachtwoorden of .env-bestanden worden bijgehouden in Git, ook niet in eerdere commits. Meld alleen bestandsnamen, geen waarden.

Veelgemaakte fouten

• Geheimen committen. Zodra een sleutel in de Git-geschiedenis staat, ligt hij bloot, ook als je het bestand later verwijdert. Vervang de sleutel.
• Eén enorme commit per week. Je kunt dan één wijziging niet ongedaan maken zonder alle andere ook terug te draaien.
• Berichten zoals ‘update’. De geschiedenis wordt nutteloos om te vinden wat er kapotging.
• Prompten op verouderde code. Pull eerst als iemand anders aan de code werkt.
• Force-pushen om een fout te herstellen. Dat kan het werk van anderen wissen. Gebruik revert.
• node_modules committen. Het is enorm en wordt toch opnieuw aangemaakt vanuit het lock-bestand.

Checklist

• Het project is gekoppeld aan een privé-repository.
• .gitignore sluit .env, node_modules, build-uitvoer en geheimen uit.
• Ik commit na elke wijziging die werkt.
• Commitberichten zeggen in één regel wat er veranderde.
• Grote of riskante wijzigingen gaan op een branch en worden gecontroleerd.
• Ik pull voordat ik prompt als iemand anders aan de code werkt.
• Ik draai terug met checkpoints of git revert, niet met force-push.
• Elke sleutel die ooit is gecommit, is vervangen.

Git op Mythex

Mythex slaat na elke geslaagde agent-beurt een git-checkpoint op, en Terugzetten naar dit punt zet het project terug naar dat punt. Dat is de undo aan de builder-kant die in stap 5 is beschreven. Zie Itereren zonder opnieuw te bouwen.

Op Pro koppelt GitHub-sync een repository vanuit de projectinstellingen, zodat je kunt pushen en pullen, en exporteren downloadt het project zonder geheimen en node_modules. Zie GitHub, export en import. Als je GitHub koppelt voordat je een project aan een developer overdraagt, wordt de overdracht veel eenvoudiger. Zie hoe je met een developer werkt aan een met AI gebouwde app en hoe je een met AI gebouwde app exporteert en zelf hostt.

Veelgestelde vragen