Praxisguide für Teams
Sie beschreiben das Ziel in natürlicher Sprache. ChatGPT hilft dabei, den vorhandenen Code zu verstehen, Änderungen strukturiert umzusetzen und den Weg bis zum Pull Request nachvollziehbar zu machen.
„Erstelle eine neue Landingpage unter /test und orientiere dich am bestehenden Design.“
Ich prüfe zuerst Routing, Styles und Projektregeln. Danach setze ich die neue Seite isoliert um.
Das Grundprinzip
Gute Zusammenarbeit beginnt nicht mit „Schreib mir Code“, sondern mit Kontext. Welches Repository? Was ist das Ziel? Welche Bereiche dürfen verändert werden? Was soll ausdrücklich unverändert bleiben?
Anschließend kann ChatGPT vorhandenen Code lesen, relevante Dateien finden, Änderungen vorbereiten und den GitHub-Workflow unterstützen. Wie weit das direkt geht, hängt von der verwendeten ChatGPT-Umgebung und den freigegebenen GitHub-Berechtigungen ab.
Der komplette Ablauf
Der wichtigste Unterschied zu klassischem „Copy & Paste Coding“: ChatGPT arbeitet direkt mit dem Kontext des Projekts und kann Änderungen entlang eines nachvollziehbaren Git-Workflows vorbereiten.
Starten Sie mit dem Ziel, nicht mit der technischen Lösung. Beschreiben Sie, was sich für Nutzerinnen und Nutzer ändern soll, welche Seite oder Funktion betroffen ist und was unverändert bleiben muss.
ChatGPT kann – abhängig von der freigegebenen GitHub-Verbindung – Repositorys durchsuchen, relevante Dateien lesen und bestehende Strukturen erkennen. Das ist wichtig, bevor Code verändert wird.
Größere Änderungen gehören auf einen eigenen Branch. So bleibt main stabil, Änderungen sind nachvollziehbar und können vor dem Merge separat geprüft werden.
Jetzt kann ChatGPT neue Routen, Komponenten, Styles oder Logik anlegen und bestehende Dateien aktualisieren. Gute Änderungen bleiben klein genug, um sie später sinnvoll reviewen zu können.
Vor dem Merge sollten Diff, betroffene Dateien, mögliche Konflikte, Build- oder CI-Status sowie sensible Bereiche geprüft werden. Bei fehlenden automatischen Tests sollte das offen benannt werden.
Der Pull Request bündelt die Änderung: Titel, Beschreibung, Umfang und technische Details. Nach Review und erfolgreichen Checks kann gemergt und der Arbeits-Branch anschließend wieder aufgeräumt werden.
Was dabei technisch passiert
Relevante Dateien, Verzeichnisse und Dokumentation werden aus dem freigegebenen Repository gelesen. So basiert die Antwort auf Ihrem echten Projekt statt auf einem erfundenen Beispiel.
Branches, Commits und Pull Requests sorgen dafür, dass jede Änderung sichtbar bleibt und bei Bedarf verglichen, reviewed oder zurückgenommen werden kann.
Sie müssen für viele Aufgaben keine Git-Befehle auswendig kennen. Sie formulieren Absicht und Einschränkungen – die technischen Schritte können daraus abgeleitet werden.
Die normale GitHub-App in ChatGPT kann je nach Produktbereich primär zum Lesen, Suchen und Analysieren von Repository-Inhalten dienen. Direkte Codeänderungen, Commits oder Pull Requests benötigen eine Umgebung mit dafür freigeschalteten Coding-/Agentenfunktionen oder autorisierten GitHub-Schreibaktionen.
Offizielle OpenAI-Hinweise zur GitHub-VerbindungPrompts, die in echten Projekten helfen
Gute Prompts nennen Ziel, Umfang, gewünschte Arbeitsweise und Grenzen. Diese Beispiele können Sie direkt als Vorlage verwenden und an Ihr Repository anpassen.
@GitHub Erstelle im Repository eine neue Landingpage unter /test. Analysiere zuerst die bestehende Struktur. Nutze das vorhandene Designsystem, arbeite möglichst isoliert und erkläre mir anschließend, welche Dateien du geändert hast.@GitHub Finde heraus, warum das mobile Menü auf kleinen Displays nicht funktioniert. Suche zuerst die relevante Komponente und Styles. Behebe nur die eigentliche Ursache und vermeide einen größeren Refactor.@GitHub Prüfe zuerst den aktuellen Stand von main. Erstelle danach einen Feature-Branch, setze die Änderung dort um, vergleiche anschließend mit main und öffne einen Pull Request. Nichts force-pushen und keine bestehende Historie umschreiben.@GitHub Prüfe diesen Pull Request wie ein Reviewer. Achte auf Funktion, Seiteneffekte, unnötige Änderungen, fehlende Fehlerbehandlung und mögliche Probleme auf Mobile. Ändere noch nichts, sondern gib mir zuerst die Befunde.Ein realistisches Beispiel
Aus einem einzigen Satz kann ein sauberer Entwicklungsprozess werden – wenn ChatGPT nicht sofort losschreibt, sondern das Projekt zuerst liest.
Projekt prüfen Routing, Framework, Styling, bestehende Komponenten und Repository-Regeln lesen.
Umfang definieren Neue Route und Styles isolieren; bestehende Landingpage möglichst nicht verändern.
Implementieren Route, responsive Layouts, Inhalte, Meta-Daten und interne Navigation ergänzen.
Router & Sitemap Sicherstellen, dass die neue Route erkannt und – falls gewünscht – öffentlich indexiert wird.
Diff prüfen Nur erwartete Dateien sollten verändert sein. Unnötige Nebenänderungen werden wieder entfernt.
Review & Merge Pull Request verständlich beschreiben, Checks prüfen und erst dann mergen.
Wofür sich die Zusammenarbeit eignet
Neue Seiten, Komponenten, Formulare, API-Anbindungen oder kleine Produktfunktionen aus einer Beschreibung heraus umsetzen.
Nach Funktionen, Fehlermeldungen oder Dateinamen suchen, Ursache eingrenzen und gezielt beheben.
Unbekannte Projekte, Datenflüsse, Routing, Komponenten und Abhängigkeiten verständlich zusammenfassen.
Duplikate reduzieren, Komponenten schneiden oder Strukturen verbessern – mit bewusst begrenztem Umfang.
Diffs lesen, Risiken benennen, Änderungen zusammenfassen und Review-Kommentare vorbereiten.
README, Setup-Hinweise, technische Entscheidungen und Arbeitsabläufe parallel zum Code aktuell halten.
Sicher arbeiten
ChatGPT kann Entwicklung stark beschleunigen. GitHub bleibt dabei das nachvollziehbare Protokoll, und die menschliche Entscheidung bleibt der letzte Kontrollpunkt.
Keine Secrets, API-Keys oder Zugangsdaten in Prompts oder Commits schreiben.
Vor Änderungen zuerst Repository-Regeln wie AGENTS.md, CONTRIBUTING.md oder README prüfen.
Für größere Arbeiten einen Branch statt direkter Änderungen auf main verwenden.
Force-Push, History-Rewrites und große Nebenänderungen vermeiden, wenn sie nicht ausdrücklich nötig sind.
Vor dem Merge Diff, Konflikte und verfügbare Checks prüfen; fehlende Tests transparent benennen.
Bei Datenbank-, Auth-, Zahlungs- oder Produktionsänderungen zusätzliche menschliche Prüfung einplanen.
Gute Rollenverteilung
FAQ
Nur Repositorys und Inhalte, für die die jeweilige GitHub-Verbindung Zugriff erhalten hat. Welche Funktionen verfügbar sind, hängt zusätzlich von Plan, Workspace, Produktbereich und Berechtigungen ab.
Technisch können autorisierte Schreibaktionen das ermöglichen. Für nachvollziehbare Entwicklung ist bei größeren Änderungen ein eigener Branch mit anschließendem Pull Request meist die bessere Arbeitsweise.
Für viele alltägliche Aufgaben nicht im Detail. Grundverständnis für Branch, Commit, Pull Request, Review und Merge hilft aber dabei, Entscheidungen bewusst zu treffen und Änderungen sicher freizugeben.
Passwörter, private Schlüssel, Tokens, API-Secrets oder andere Zugangsdaten. Solche Werte gehören in geeignete Secret- und Environment-Verwaltung – nicht in Chatverläufe oder Commits.
Den Scope explizit begrenzen: betroffene Seite nennen, erlaubte Dateien oder Bereiche beschreiben, bestehende Funktionalität schützen und vor dem Merge den Diff gegen main prüfen lassen.
Der einfachste Einstieg
Repository nennen, Ziel erklären, Grenzen setzen – und ChatGPT zuerst den vorhandenen Code verstehen lassen. Genau daraus entsteht ein guter gemeinsamer Entwicklungsprozess.