Was ist GitHub? Versionskontrolle für Nicht-Entwickler

GitHub ist eine Website, die den Code von Softwareprojekten zusammen mit ihrer vollständigen Historie speichert. So siehst du jede Änderung, machst Fehler rückgängig und arbeitest mit anderen Personen am selben Projekt. Die Plattform basiert auf Git, einer kostenlosen Software, die Schnappschüsse der Dateien eines Projekts über die Zeit festhält. Git ist das Werkzeug, das die Historie führt. GitHub ist das Online-Zuhause, in dem diese Historie geteilt, gesichert und besprochen wird.

Wenn du mit KI baust, dreht sich GitHub vor allem um zwei Dinge: eine eigene Kopie deines Codes außerhalb des Werkzeugs zu besitzen, in dem du ihn gebaut hast, und den Code an einen Entwickler zu übergeben, und zwar in dem Format, mit dem er ohnehin arbeitet.

Warum es beim Bauen mit KI wichtig ist

Ein KI-App-Builder schreibt und ändert schnell eine Menge Code, und nicht jede Änderung ist eine Verbesserung. Versionskontrolle hilft dir, dabei den Überblick zu behalten.

• Sicher rückgängig machen. Jede gespeicherte Änderung ist ein Schnappschuss. Wenn die KI etwas kaputt macht, kehrst du zum letzten guten Stand zurück.
• Besitz. Code in deinem eigenen GitHub-Konto bleibt deiner, wenn du das Werkzeug wechselst, ein Abo kündigst oder eine zweite Meinung einholen willst.
• Zusammenarbeit mit Entwicklern. Fast jeder Entwickler nutzt Git täglich. Ein Repository erlaubt ihm, zu prüfen, was die KI geschrieben hat, es zu korrigieren und Änderungen zurückzuschicken.
• Woanders deployen. Viele Hosting-Plattformen können direkt aus einem GitHub-Repository deployen.

Ein Alltagsvergleich: Änderungen nachverfolgen plus ein gemeinsames Laufwerk

Stell dir ein Dokument mit aktivierter Änderungsnachverfolgung vor, das auf einem gemeinsamen Laufwerk liegt.

• Git ist die Änderungsnachverfolgung: Jede Bearbeitung wird festgehalten, mit Angabe, wer sie wann und warum gemacht hat, und du kannst zu jeder Version zurückspringen.
• GitHub ist das gemeinsame Laufwerk: Das Dokument liegt online, andere können eine Kopie holen, und es gibt einen Ort zum Kommentieren und Freigeben.
• Ein Branch ist wie eine Kopie mit dem Namen „Entwurf – neuer Preisabschnitt“. So kannst du etwas ausprobieren, ohne die Version anzufassen, auf die alle angewiesen sind. Wenn das Experiment funktioniert, führst du es wieder zusammen.

Der Unterschied zu einem Dokument liegt im Umfang. Eine App besteht aus Hunderten Dateien, und Git verfolgt alle gemeinsam. Ein Schnappschuss ist deshalb der Zustand des gesamten Projekts auf einmal.

Git- und GitHub-Begriffe, denen du begegnen wirst

Zwei Punkte sind besonders wichtig. Erstens ist die Git-Historie absichtlich dauerhaft: Wenn ein Passwort committet und hochgeladen wurde, entfernt das Löschen in einem späteren Commit es nicht aus der Historie. Zweitens ist ein Commit nur so gut wie seine Nachricht. „Doppelte Buchung behoben, wenn zwei Personen gleichzeitig buchen“ hilft dir später weiter. „update“ nicht.

Ein Beispiel: eine mit KI gebaute App an einen Freelancer übergeben

Du hast mit einem KI-App-Builder ein Kundenportal gebaut. Es funktioniert, aber du willst, dass ein freiberuflicher Entwickler eine knifflige Anbindung an deine Buchhaltungssoftware ergänzt.

1. Verbinde das Projekt mit einem neuen privaten GitHub-Repository und lade es hoch. Das Repository enthält jetzt den Code und seine Historie.
2. Prüfe den Inhalt. Öffne das Repository auf GitHub. Dort sollte keine .env-Datei liegen und kein API-Schlüssel im Code stehen. Geheimnisse bleiben in den Einstellungen deiner Plattform und werden dem Freelancer gegebenenfalls separat weitergegeben. Siehe Umgebungsvariablen und Geheimnisse.
3. Lade den Freelancer nur für dieses Repository als Mitarbeiter ein.
4. Er arbeitet auf einem Branch mit einem Namen wie buchhaltung-sync, committet unterwegs und öffnet am Ende einen Pull Request.
5. Du prüfst den Pull Request. Auch ohne Code zu lesen, kannst du die Beschreibung lesen, sehen, welche Dateien sich geändert haben, und Fragen in den Kommentaren stellen.
6. Führe zusammen, wenn du zufrieden bist, und hole die Änderungen dann zurück in deinen App-Builder, damit du und die KI mit der neuen Version weitermachen.

Unterwegs siehst du genau, was sich geändert hat, und kannst es bei Bedarf rückgängig machen. Darin steckt der ganze Nutzen der Versionskontrolle in einem Arbeitsablauf. Wenn du überlegst, ob du überhaupt einen Entwickler einbinden willst, siehe Entwickler beauftragen oder mit KI bauen.

Häufige Fehler und Missverständnisse

• „GitHub und Git sind dasselbe.“ Git funktioniert auch ohne GitHub. Alternativen wie GitLab und Bitbucket hosten ebenfalls Git-Repositories.
• „GitHub betreibt meine App.“ GitHub speichert Code. Die App für Besucher laufen zu lassen ist Webhosting, ein eigener Dienst, auch wenn manche Hoster aus GitHub deployen.
• Geheimnisse committen. Der schädlichste und häufigste Fehler. Nutze .gitignore für .env-Dateien und tausche jeden Schlüssel aus, der je hochgeladen wurde.
• Nur ein Branch und keine Nachrichten. Für Solo-Experimente reicht das, aber gib Commits klare Nachrichten und nutze Branches für alles Riskante.
• Gleichzeitig an zwei Stellen bearbeiten. Wenn du Code auf GitHub und im KI-Builder änderst, ohne dazwischen zu synchronisieren, entstehen Konflikte. Bearbeite immer nur an einer Stelle und synchronisiere, bevor du wechselst.
• Denken, ein privates Repository sei ein vollständiges Backup. Es enthält Code, nicht den Inhalt deiner Datenbank oder hochgeladene Dateien. Dafür brauchst du eigene Backups.

Was du deinen KI-App-Builder fragen solltest

• „Füge eine .gitignore hinzu, die .env, Abhängigkeitsordner und Build-Ausgaben ausschließt.“
• „Schreibe eine README, die erklärt, wie man installiert, welche Umgebungsvariablen nötig sind (nur die Namen) und wie man die App startet.“
• „Lege eine .env.example mit allen Variablennamen und ohne echte Werte an.“
• „Verwende für jede Änderung klare, aussagekräftige Commit-Nachrichten.“

Mit diesen vier Anfragen entsteht ein Repository, das ein Entwickler in wenigen Minuten übernehmen kann. Um die App auf eigene Server zu verlagern, siehe wie du eine mit KI gebaute App exportierst und selbst hostest. Um sie vor echten Nutzern abzusichern, siehe einen KI-Prototyp in die Produktion bringen.

GitHub und Mythex

Mythex speichert die Historie für dich, in jedem Tarif: Nach jedem erfolgreichen Durchlauf des Agenten legt es einen Checkpoint an, also einen Git-Schnappschuss, zu dem du zurückkehren kannst. Im Pro-Tarif kannst du GitHub verbinden und das Projekt gegen dein eigenes Repository pushen oder pullen. Alternativ lädst du das ganze Projekt als Archiv herunter. Geheimnisse und installierte Abhängigkeiten sind von Exporten ausgeschlossen. GitHub dient hier dem Synchronisieren von Code, nicht der Anmeldung bei Mythex. Siehe GitHub, Export und Import in der Dokumentation und die Preisseite für die Leistungen jedes Tarifs.

Fragen