Nutzt du GitHub, ohne wirklich zu wissen, was du tust?
Wer blind drauflosklickt, macht schnell etwas kaputt.
Auf GitHub gibt es nur drei grüne Buttons.
Und es gibt nur eine Stelle, auf die du schauen solltest, bevor du sie drückst.
Dieser Artikel zeigt dir jede Stelle auf dem GitHub-Bildschirm, auf die du achten und klicken musst – markiert mit roten Kästen.
Verbinden, einreichen, Diff prüfen, mergen und rückgängig machen.
Wir gehen diesen kompletten Zyklus anhand von 10 echten Screenshots durch.
Die KI übernimmt das Tippen.
Du schaust hin und klickst.
Schwierige Begriffe erkläre ich einfach und verständlich, sobald sie auftauchen.
※ Die GitHub-Oberflächen und Funktionen in diesem Artikel wurden im Oktober 2026 geprüft. Das Design kann sich ändern.
Kapitel 1: Mit GitHub verbinden | Repository erstellen und lokale Daten hochladen
Die GitHub-Oberfläche ist auf Englisch.
Aber die Stellen, auf die du klicken musst, sind immer dieselben.
Die roten Kästen auf den Screenshots zeigen dir genau, wo du hinschauen und wo du klicken musst.
In diesem Kapitel gibt es nur einen einzigen grünen Button zum Drücken.
Erstelle zuerst ein Repository.
Ein Repository ist wie ein Spind, in dem du deine Git-Daten online ablegst.
Was genau in diesem Spind liegt und welche vier Schlüsselbegriffe du kennen musst, habe ich in meinem letzten Beitrag erklärt.
【Mit Diagrammen】Git für Mittelschüler erklärt
https://x.com/dan_pro_man/status/2107224533099069671?s=20
Aber selbst wenn du ihn nicht gelesen hast, kannst du den gesamten Zyklus allein mit diesem Artikel durchlaufen.
Logge dich bei GitHub ein und wähle über das „+“-Symbol oben rechts „New repository“ aus.
Wenn du https://github.com/new öffnest, landest du auf derselben Seite.
Du musst nur einen Namen eingeben.
Trage unter „Repository name“ einen alphanumerischen Namen ein.
„git-practice“ passt perfekt.
Wähle unter „Choose visibility“ die Option „Private“.
Das bedeutet: nicht öffentlich.
Lass den Schalter bei „Add README“ vorerst ausgeschaltet.
Wenn du bereits lokale Daten hast, ist die Verbindung einfacher, wenn du ein leeres Repository erstellst.
Klicke unten auf den grünen Button „Create repository“.
Der Bildschirm direkt nach dem Klick ist der wichtigste Teil dieses Kapitels.
Weiter unten findest du die Überschrift: „…or push an existing repository from the command line“.
Die drei Zeilen darunter sind die Befehle, die wir heute verwenden werden.
Die sieben Zeilen darüber sind für Leute gedacht, die noch keine lokalen Daten haben – die kannst du also überspringen.
Das bedeuten die drei Zeilen:
Zeile 1: Deinen lokalen Daten die Adresse dieses Spinds mitteilen.
Zeile 2: Den Namen des Haupt-Branches auf „main“ festlegen.
Zeile 3: Den Haupt-Branch im Spind ablegen.
Kopiere die Adresse (roter Kasten) von diesem Bildschirm und schicke sie in einer Zeile an die KI.
1Lade die Daten in diesem Ordner auf https://github.com/account-name/git-practice hoch
Claude Code tippt die drei Zeilen dann selbst ein.
Claude Code ist eine KI, die Aufgaben auf deinem Computer nach deinen Anweisungen ausführt.
In meiner Bedienungsanleitung verlange ich eine Bestätigung vor dem Pushen.
Pushen bedeutet, die lokalen Daten im Spind abzulegen.
Deshalb stoppt der Vorgang hier kurz.
Antworte mit „Yes“ und lade dann die Browserseite neu.
Wo eben noch die drei Befehle standen, sind jetzt deine lokalen Dateien aufgelistet. Daneben steht die Commit-Nachricht.
Das ist das Zeichen dafür, dass du „verbunden“ bist.
Hier ist eine Sache, die mir auffallen soll.
Der Text „main“ über der Dateiliste.
Er zeigt an, welches Lesezeichen du gerade im Spind ansiehst.
Ein Lesezeichen ist ein Branch.
Es markiert, in welcher Spalte du deine Daten stapelst.
Fasse dieses „main“ ab jetzt nicht mehr direkt an.
Anfangs habe ich darauf auch nicht besonders geachtet.
Ich habe direkt auf main gearbeitet und viel Zeit damit verschwendet, herauszufinden, wie ich wieder zurückkomme.
Wenn Verbindungen fehlschlagen, liegt es meistens an der Adresse.
Das „.git“ am Ende fehlt.
Der Account-Name ist falsch geschrieben.
Wenn du „not found“ siehst, kopiere die Adresse einfach nochmal aus Bild ②.
Deine lokalen Daten sind nun mit GitHub verbunden. Als Nächstes kommt der tägliche Zyklus des Mergens über Pull Requests.
**
Kapitel 2: Über einen Pull Request mergen | KI-Arbeit einreichen, Diff prüfen und dann klicken
Ab hier beginnt der tägliche Zyklus.
Ein Pull Request ist eine Einreichung mit der Bitte: „Bitte merge das.“
In diesem Kapitel gibt es drei grüne Buttons zum Klicken.
Die KI übernimmt das Tippen.
Deine Aufgabe ist es nur, hinzuschauen und zu klicken.
Schick der KI zuerst eine Zeile.
1Erstelle einen neuen Branch, füge dem README 3 Zeilen zur Nutzung hinzu, committe und lade alles auf GitHub hoch
Das README ist die erste Datei, in der du die Beschreibung des Repositories schreibst.
Claude Code erstellt einen Branch.
Es ändert die Datei und committet.
Zum Schluss stoppt es vor dem Pushen und fragt nach.
Antworte mit „Yes“ und öffne dann den Spind in deinem Browser.
Oben erscheint ein gelbes Banner.
Es informiert dich: „Ich habe gerade diesen Branch abgelegt.“
Klicke rechts auf den grünen Button „Compare & pull request“.
Das ist die ‚Einreichung‘.
Wie wenn du dein Entwurfsheft dem Lehrer gibst.
Nur durch das Einreichen wird noch nichts in die finale Version übernommen.
Das Kopieren passiert erst nach dem Review.
Auf dem Einreichungsbildschirm gibt es drei Stellen, auf die du achten musst.
1.: Der Pfeil ganz oben.
„base: main“ und „compare: work-branch“
Das zeigt, von wo nach wo gemergt wird.
Stelle einfach sicher, dass links „main“ steht.
2.: Der Titel unter „Add a title“.
Wenn die KI ihn generiert, enthält er eine Zusammenfassung der Änderungen.
Wenn du manuell einreichst, ist die Commit-Nachricht vorausgefüllt.
Bei manueller Einreichung schreibe in einer Zeile, „was gemacht wurde“.
3.: Der grüne Button „Create pull request“.
Ein Klick darauf nimmt die Einreichung an.
Nach der Einreichung bist du als Mensch gefragt.
Oben auf dem Bildschirm erscheinen vier Tabs.
Schaue nur auf den Tab ganz rechts: „Files changed“.
Das bedeutet: geänderte Dateien.
Grüne Zeilen sind hinzugefügte Zeilen.
Rote Zeilen sind gelöschte Zeilen.
Das ist der Diff.
Wenn die 3 angeforderten Zeilen grün sind, ist alles in Ordnung.
Im Beispielbild wurden auch Überschriften und Leerzeilen hinzugefügt, weshalb es 6 grüne Zeilen sind.
Wenn es rote Zeilen gibt, die du nicht angefordert hast, merge nicht.
Im Beispielbild gibt es 1 rote Zeile.
Eine Memo-Zeile ist unter „Items placed“ verschwunden.
Wenn du das nicht verlangt hast, stoppe hier.
Frage die KI: „Warum hast du diese rote Zeile gelöscht?“
Das sind die wichtigsten 30 Sekunden, wenn du Arbeit an die KI delegierst.
Früher, als mir schon bei reinen Review-Benachrichtigungen flau im Magen wurde, habe ich oft geklickt, ohne das zu prüfen.
Heute zähle ich zuerst die roten Zeilen.
Wenn auch nur eine einzige ungewollte rote Zeile dabei ist, stoppe ich.
Wenn mit dem Diff alles stimmt, gehe zurück zu „Conversation“.
Weiter unten findest du den grünen Button „Merge pull request“.
Wenn darüber „No conflicts with base branch“ steht, kannst du direkt mergen.
Nach dem Klick ändert sich der Text zu „Confirm merge“.
Klicke erneut darauf.
Jetzt sind die Daten des Arbeits-Branches in main gemergt.
Die Farbe wechselt zu Lila und es steht dort „Merged“.
Darunter erscheint ein Kasten mit der Meldung „Pull request successfully merged and closed“.
Rechts daneben steht „Delete branch“.
Klicke ruhig darauf.
Es verschwindet nur das „Lesezeichen“ des Arbeits-Branches im Spind.
Da die Daten bereits in main gemergt sind, geht nichts verloren.
Aktualisiere zum Schluss deine lokale Umgebung.
Sag der KI: „Wechsle zu main und hole den neuesten Stand von GitHub.“
Damit ist ein Zyklus abgeschlossen.
Starte die nächste Aufgabe immer von einem neuen Branch aus.
Arbeite nicht auf main.
Du hast nun den Zyklus aus Einreichen, Diff prüfen und Mergen gemeistert. Als Nächstes geht es um Revert – den Button, um Fehler nach dem Mergen rückgängig zu machen.
**
Kapitel 3: Revert | Fehler nach dem Mergen mit einem Klick rückgängig machen
Manchmal fallen dir Fehler erst nach dem Mergen auf.
In Git machst du gespeicherte Daten „rückgängig“, ohne sie zu löschen.
Auf dem GitHub-Bildschirm gibt es dafür einen Button.
Er heißt „Revert“.
Öffne den Pull Request, den du gerade gemergt hast, noch einmal.
Dort steht eine Zeile: „merged commit … into main“.
Ganz rechts in dieser Zeile findest du „Revert“.
Was passiert, wenn du darauf klickst?
Daten werden nicht gelöscht.
Es wird ein neuer Pull Request mit den entgegengesetzten Änderungen erstellt.
Laut offizieller Dokumentation findet der Merge statt, wenn du diesen neuen Pull Request mergst.
Ein Revert folgt also demselben Zyklus wie in Kapitel 2.
Diff prüfen, grünen Button klicken.
Anstatt etwas zu löschen, wird ein Eintrag mit „reverted“ hinzugefügt.
Wenn du die KI fragst, sag: „Mache den Pull Request, den ich gerade gemergt habe, rückgängig.“
Claude Code erledigt dasselbe mit git revert.
Es gibt noch einen weiteren Bildschirm, der dir begegnen könnte.
„This branch has conflicts that must be resolved“.
Das ist ein Konflikt.
Er entsteht, wenn dieselbe Zeile in main und im Arbeits-Branch unterschiedlich geändert wurde.
Der grüne Button wird grau und lässt sich nicht mehr anklicken.
Behebe das nicht manuell auf dem Bildschirm, sondern schick der KI eine Zeile.
1Hole main und zeige mir beide Versionen der konfliktbehafteten Stellen
Du entscheidest, welche Version behalten wird.
Sobald die KI das Problem behoben und alles erneut hochgeladen hat, ist der grüne Button wieder da.
Konflikte sind keine Fehler.
Sie zeigen lediglich, dass dieselbe Zeile zweimal bearbeitet wurde.
Zum Schluss noch etwas, das nicht auf dem Bildschirm auftaucht.
Keys.
Dateien mit Passwörtern oder API-Keys dürfen niemals auf GitHub hochgeladen werden.
Selbst wenn du einen Revert machst: Sobald ein Key hochgeladen wurde, gilt er als kompromittiert und muss neu generiert werden.
Sag der KI vor dem Hochladen: „Schließe .env von den Daten aus.“
In meinem eigenen Job schreibe ich AWS-Konfigurationen in Textdateien und folge exakt diesem Zyklus.
Konfigurationen, die ohne Diff-Prüfung gemergt werden, laufen direkt in der Produktion.
Deshalb delegiere ich diese entscheidenden 30 Sekunden vor dem Klick nicht an die KI.
Alle Buttons auf dem Bildschirm werden von Menschen gedrückt.
Selbst wenn ich der KI immer mehr Aufgaben übertrage, bleibt diese Regel bestehen.
Damit ist der komplette Zyklus aus Verbinden, Einreichen, Mergen und Revert abgeschlossen.
Zum Schluss bekommst du fertige Materialien von mir.
Ich habe die Schritte für einen kompletten Zyklus auf der GitHub-Oberfläche aufgeschrieben.
Die Screenshots und Prompts aus diesem Artikel habe ich in sofort nutzbare Formate gepackt.
- GitHub-Bildschirm-Übersetzungsposter (9 Screenshots, 69 Begriffe)
- Wiederherstellungsplan, wenn die KI etwas kaputt macht (6 Szenarien)
- 7 Prompts für einen kompletten Zyklus
- Checkliste vor dem Mergen (8 Punkte)
Alles zusammen geliefert als 15-seitiges PDF-Booklet.
Damit allein kannst du noch heute anfangen, Zyklen abzuschließen.
Um sie zu erhalten, tritt einfach dem Open Chat unten bei.
Folge den Anweisungen nach dem Beitritt, sende „Submit“ und du bekommst sie automatisch zugeschickt.
https://line.me/ti/g2/pEpZQdEyn1BM5Zi2wqLBT2rZYpC0ZaOncIWTag
Fazit: Schließe heute einfach einen Zyklus ab
Übernimm KI-Arbeit niemals direkt in main.
Reiche sie über einen Arbeits-Branch ein, prüfe den Diff und klicke auf die grünen Buttons.
In einem Zyklus gab es drei grüne Buttons zum Klicken.
An dem Tag, an dem ich zum ersten Mal selbst auf Revert geklickt habe, wurde mir klar, dass dabei keine Daten gelöscht werden.
Danach hatte ich keine Angst mehr, Dinge anzufassen.
Du musst nicht alles auf einmal machen.
Für heute gibt es nur eine einzige Aufgabe.
Öffne das in Kapitel 1 erstellte Repository und schick der KI eine Zeile.
Erstelle einen neuen Branch, füge dem README 1 Zeile hinzu und lade alles auf GitHub hoch
Wenn das gelbe Banner erscheint, klicke auf den grünen Button und öffne „Files changed“.
Wenn es nur eine grüne Zeile gibt, ist alles in Ordnung.
Schau dir diese eine Zeile mit eigenen Augen an, bevor du mergst.
Das ist der erste Schritt, um mehr Aufgaben an die KI zu delegieren.
Für Engineers über 30 entscheidet nicht das Arbeitsvolumen über den Erfolg, sondern das Design.
Anstatt Tools bei jedem Update neu zu lernen, ist es schneller zu definieren, wo du einen Stopp setzt.
AWS und KI entwickeln sich rasant weiter.
Logs von Leuten zu lesen, die im echten Arbeitsalltag testen, bringt dich schneller voran, als alleine hinterherzuhecheln.
In meiner Praxis mit KI × Engineering hinterlasse ich nicht nur erfolgreiche Ergebnisse, sondern auch kaputte und aussortierte.
Folge mir, damit du keine zukünftigen Erkenntnisse verpasst! @dan_pro_man
