So nutzt du Git mit einer KI-gebauten App

Um Git mit einer KI-gebauten App zu nutzen, verbindest du das Projekt mit einem Git-Repository, committest nach jeder funktionierenden Änderung, schreibst eine einzeilige Nachricht, die beschreibt, was sich geändert hat, und hältst Geheimnisse mit einer .gitignore aus dem Repository heraus. Nutze einen Branch für alles Riskante, ziehe die Änderungen, bevor du wieder promptest, wenn jemand anderes den Code geändert hat, und wenn die KI etwas kaputt macht, gehst du zum letzten guten Commit zurück, statt auf dem Chaos weiterzuprompten.

Git ist Versionskontrolle: eine Historie jeder gespeicherten Version deines Codes. GitHub ist eine Website, die Git-Repositories online speichert. Wenn dir das neu ist, fang mit was GitHub ist an. Dieser Leitfaden handelt von den Gewohnheiten, die Git nützlich machen, wenn eine KI den Großteil des Codes schreibt.

Warum Git mit KI wichtiger ist

Eine KI kann in einer einzigen Runde zwanzig Dateien ändern. Das ist schnell, heißt aber auch, dass ein einziger Prompt still und leise etwas kaputt machen kann, das du gestern noch getestet hast. Git gibt dir:

• Einen Weg zurück. Jede committete Version lässt sich wiederherstellen.
• Eine Aufzeichnung der Änderungen. Du siehst genau, welche Dateien und Zeilen ein Prompt angefasst hat.
• Eine Kopie außerhalb des Builders. Dein Code liegt an einem Ort, den du kontrollierst.
• Eine Standardübergabe. Jeder Entwickler, jeder Hoster und jedes Tool kann mit einem Git-Repository arbeiten.

Schritt 1: Ein Repository verbinden

Lege ein Repository an (meist privat) auf GitHub oder einem ähnlichen Dienst und verbinde dein Projekt damit. Die meisten KI-App-Builder, die Git unterstützen, machen das über eine Einstellungsseite mit einem Button „Mit GitHub verbinden“. Wenn deiner das nicht hat, kannst du den Code exportieren und selbst hochladen, oder einen Entwickler bitten, es einmal einzurichten.

Bevor der erste Push passiert, stelle sicher, dass das Repository alles ignoriert, was nicht hineingehört:

Prüfe die Datei .gitignore. Stelle sicher, dass sie .env-Dateien, node_modules, Build-Ausgabeordner und alle Dateien mit Geheimnissen ausschließt. Sag mir, was du hinzugefügt hast.

Schritt 2: Nach jeder funktionierenden Änderung committen

Ein Commit ist ein gespeicherter Snapshot mit einer Nachricht. Die Gewohnheit, auf die es ankommt: Committe, wenn etwas funktioniert, bevor du nach dem nächsten fragst.

1. Prompte für eine Änderung.
2. Prüfe sie in der Vorschau.
3. Wenn sie funktioniert, committe (oder synchronisiere) mit einer Nachricht.
4. Dann mache weiter.

Kleine Commits bedeuten: Wenn etwas bricht, weißt du, welche Änderung es war, und das Rückgängigmachen wirft keine anderen Arbeiten weg.

Schritt 3: Nachrichten schreiben, die du später lesen kannst

Eine gute Nachricht sagt in einer Zeile, was sich geändert hat und warum:

• Gut: CSV-Export zur Bestellseite hinzufügen
• Gut: Fehler behoben: Buchungsformular lehnt Uhrzeiten nach 18 Uhr ab
• Nicht hilfreich: update, changes, fix stuff

Du kannst die KI bitten, sie zu schreiben:

Fasse die Änderungen seit dem letzten Commit in einer Zeile zusammen, beginne mit einem Verb und bleibe unter 70 Zeichen.

Schritt 4: Branches für riskante Arbeit nutzen

Ein Branch ist eine eigene Linie der Arbeit. Du kannst etwas auf einem Branch ausprobieren und, wenn es nicht klappt, aufgeben, ohne die Hauptversion anzufassen.

Nutze einen Branch, wenn:

• Die Änderung groß ist (ein Redesign, ein neuer Zahlungsablauf, eine Datenbankänderung).
• Jemand anderes an derselben App arbeitet.
• Du möchtest, dass jemand die Änderung prüft, bevor sie live geht.

Wenn die Arbeit fertig und getestet ist, wird sie wieder in den Hauptbranch gemergt. Auf GitHub passiert das meist über einen Pull Request, eine Seite, die die Änderungen zur Prüfung zeigt. Wenn dein Builder nur einen Branch synchronisiert, kann ein Entwickler die Branches auf der GitHub-Seite verwalten.

Schritt 5: Sicher rückgängig machen

Wenn ein Prompt die App kaputt macht, widerstehe dem Drang, fünfmal auf dem Fehler weiterzuprompten. Geh zur letzten guten Version zurück und versuche einen klareren Prompt.

• Im Builder: Nutze dessen Checkpoint- oder Wiederherstellungsfunktion, falls vorhanden.
• In Git: git revert erstellt einen neuen Commit, der einen alten rückgängig macht, und bewahrt so die Historie. Das ist die sichere Wahl für Code, den andere bereits gezogen haben.
• Vermeide git push --force auf einem geteilten Branch, außer du weißt genau, warum. Es schreibt die Historie für alle neu.

Wenn du unsicher bist, frag:

Die letzte Änderung hat die Login-Seite kaputt gemacht. Zeig mir, welche Dateien sie im Vergleich zum vorherigen Commit geändert hat, und erkläre, was jede Änderung getan hat. Ändere noch nichts.

Schritt 6: Vor dem Prompten ziehen

Wenn ein Entwickler oder ein anderes Tool den Code auf GitHub ändert, weiß der KI-Builder das nicht, bis du diese Änderungen per Pull einholst. Auf altem Code zu prompten führt zu Konflikten und verlorener Arbeit.

• Ziehe die Änderungen zu Beginn jeder Sitzung.
• Vereinbart, wer was bearbeitet, und vermeidet, dass beide Seiten gleichzeitig dieselben Dateien ändern.
• Wenn du einen Merge-Konflikt hast (zwei Änderungen an denselben Zeilen), bitte den Entwickler oder die KI, ihn zu lösen und die Entscheidung zu erklären.

Beispiel-Prompts

Bevor wir anfangen: Was hat sich seit meiner letzten Sitzung im Repository geändert? Fasse die Commits zusammen.

Mach die nächste Änderung für sich allein: Füge jeder Rechnung einen Button „Duplizieren“ hinzu. Ändere nichts anderes, damit ich sie separat committen kann.

Prüfe, ob API-Schlüssel, Passwörter oder .env-Dateien in Git verfolgt werden, auch in früheren Commits. Nenne nur Dateinamen, keine Werte.

Häufige Fehler

• Geheimnisse committen. Sobald ein Schlüssel in der Git-Historie steht, ist er offengelegt, auch wenn du die Datei später löschst. Tausche ihn aus.
• Ein riesiger Commit pro Woche. Du kannst eine Änderung nicht rückgängig machen, ohne alle anderen mit zurückzudrehen.
• Nachrichten wie „update“. Die Historie wird nutzlos, wenn du finden willst, was kaputt gegangen ist.
• Auf veraltetem Code prompten. Ziehe zuerst, wenn jemand anderes bearbeitet.
• Mit Force-Push einen Fehler beheben. Das kann die Arbeit anderer Leute löschen. Nutze stattdessen Revert.
• node_modules committen. Der Ordner ist riesig und wird aus der Lock-Datei ohnehin neu erzeugt.

Checkliste

• Das Projekt ist mit einem privaten Repository verbunden.
• .gitignore schließt .env, node_modules, Build-Ausgaben und Geheimnisse aus.
• Ich committe nach jeder funktionierenden Änderung.
• Commit-Nachrichten beschreiben in einer Zeile, was sich geändert hat.
• Große oder riskante Änderungen laufen über einen Branch und werden geprüft.
• Ich ziehe vor dem Prompten, wenn jemand anderes den Code bearbeitet.
• Ich mache mit Checkpoints oder git revert rückgängig, nicht mit Force-Push.
• Jeder Schlüssel, der je committet wurde, ist ausgetauscht.

Git bei Mythex

Mythex speichert nach jedem erfolgreichen Agent-Durchlauf einen Git-Checkpoint, und Zu diesem Punkt zurückkehren setzt das Projekt auf diesen Stand zurück. Das ist die builder-seitige Rückgängig-Funktion aus Schritt 5. Siehe Ohne Neuaufbau iterieren.

Im Pro-Tarif verbindet GitHub-Sync ein Repository aus den Projekteinstellungen, damit du dagegen pushen und pullen kannst, und Export lädt das Projekt herunter, wobei Geheimnisse und node_modules ausgelassen werden. Siehe GitHub, Export und Import. Wenn du GitHub verbindest, bevor du ein Projekt an einen Entwickler übergibst, wird die Übergabe deutlich einfacher. Siehe wie du mit einem Entwickler an einer KI-gebauten App arbeitest und wie du eine KI-gebaute App exportierst und selbst hostest.

Fragen