Git-Anleitung

Alles, was zwischen dem Original und deinem Rechner passiert – in einfachen Worten, mit einem Beispielprojekt zum Mitmachen. Wenn du nur eine Sache mitnimmst: Es gibt drei Orte, und fast jeder Befehl schiebt etwas von einem zum anderen.

Inhalt

1. Git ist nicht GitHub
2. Die drei Orte
3. Der Fork: deine eigene Kopie
4. Der Clone: ab auf die Festplatte
5. origin und upstream
6. Der Weg einer Änderung
7. Branches: die Nebenspur
8. Mergen: wieder einfädeln
9. Rebase: umsetzen statt zusammenführen
10. Den Fork aktuell halten
11. Der Pull Request
12. Wenn es klemmt
13. Spickzettel
14. Der typische Ablauf

01 · Git ist nicht GitHub

Das sind zwei verschiedene Dinge, und sie werden dauernd verwechselt.

Git ist ein Programm auf deinem Rechner. Es merkt sich, wie deine Dateien zu jedem Zeitpunkt aussahen. Du kannst jederzeit zurückblättern. Git funktioniert auch völlig ohne Internet.

GitHub ist eine Webseite, auf der solche Git-Projekte liegen. Sie ist der Treffpunkt: Dort liegt das Original-Projekt, dort liegt deine Kopie davon, und dort reden Leute über Änderungen.

Das Bild dazu: Git ist dein Notizbuch samt Stift. GitHub ist das Regal in der Bibliothek, in das du das Notizbuch stellst, damit andere reinschauen können. Das Notizbuch funktioniert auch zu Hause – das Regal brauchst du nur zum Teilen.

Ein Projekt, das Git verwaltet, heißt Repository, kurz Repo. Auf deinem Rechner ist das einfach ein Ordner, zum Beispiel C:\projekte\projekt, mit allem, was drin liegt.

02 · Die drei Orte

Das ist der wichtigste Abschnitt der ganzen Seite. Wenn du die drei Orte auseinanderhältst, ergibt der Rest sich fast von selbst.

• Das Original – original-team/projekt. Gehört dem Team des Originals. Du kannst reinschauen, aber normalerweise nichts hineinschreiben.
• Dein Fork – dein-name/projekt. Deine eigene Kopie, auch auf GitHub. Hier darfst du alles.
• Dein Rechner – C:\projekte\projekt. Hier arbeitest du wirklich. Nur hier gibt es Dateien zum Anfassen.

Die drei Orte und die Wege dazwischen. Zwei davon liegen auf GitHub, einer liegt bei dir auf der Festplatte – und nur dort kannst du Dateien wirklich bearbeiten. Alles, was du tippst, schiebt etwas zwischen diesen drei Kästen hin und her.

03 · Der Fork: deine eigene Kopie

Am Anfang steht das Original-Projekt auf GitHub. Es gehört dir nicht, also darfst du dort nichts verändern. Damit du trotzdem daran arbeiten kannst, drückst du auf einen Knopf, der Fork heißt. GitHub legt daraufhin eine vollständige Kopie an, die dir gehört.

Das Bild dazu: Im Regal der Bibliothek steht ein dickes Kochbuch. Du darfst nicht hineinschreiben. Also machst du eine vollständige Fotokopie und stellst sie daneben ins Regal – mit deinem Namen drauf. In deiner Kopie darfst du streichen, ergänzen, Seiten umschreiben. Das Original bleibt unangetastet.

Wichtig: Ein Fork ist eine Momentaufnahme. Wenn das Team des Originals danach weiterarbeitet, bekommt deine Kopie das nicht automatisch mit. Wie du sie nachziehst, steht in Kapitel 10.

04 · Der Clone: ab auf die Festplatte

Auf GitHub kannst du Dateien zwar ansehen, aber nicht vernünftig programmieren. Also holst du dir deinen Fork auf den Rechner. Das heißt klonen und passiert genau einmal pro Projekt.

git clone https://github.com/dein-name/projekt.git

Legt den Ordner an, lädt alle Dateien herunter – und dazu die komplette Vorgeschichte, jede je gespeicherte Version.

Ab jetzt hast du zwei Kopien: eine auf GitHub, eine bei dir. Beide wissen voneinander, aber sie gleichen sich nicht von allein ab. Das machst du von Hand, mit push und pull.

Merke: Nichts in Git passiert automatisch. Kein Speichern, kein Hochladen, kein Abgleich. Das ist anfangs lästig und später der Grund, warum du nie aus Versehen etwas kaputt machst.

05 · origin und upstream

Dein Rechner muss wissen, wohin er etwas schicken soll. Solche gespeicherten Adressen heißen Remotes – Fernverbindungen. Es sind einfach Spitznamen für Internet-Adressen.

• origin zeigt auf deinen Fork. Der Name kommt automatisch beim Klonen.
• upstream zeigt auf das Original. Den legst du selbst an, wenn du neue Versionen des Originals holen willst.

git remote add upstream https://github.com/original-team/projekt.git
git remote -v

Der erste Befehl legt die Adresse an, der zweite zeigt alle gespeicherten Adressen an. upstream ist übrigens nur ein üblicher Name, kein Zauberwort.

Das Bild dazu: Zwei Telefonnummern in deinem Adressbuch: origin ist dein eigenes Regal, upstream ist das des Verlags. Du rufst mal hier, mal dort an – aber immer absichtlich.

06 · Der Weg einer Änderung

Jetzt die eigentliche Arbeit. Eine Änderung durchläuft vier Stationen, und für jeden Schritt gibt es genau einen Befehl.

Drei Befehle, drei Stationen. Der Zwischenschritt „Bühne“ existiert, damit du auswählen kannst, welche deiner Änderungen zusammen einen Stand ergeben.

Was ist ein Commit?

Ein Commit ist ein gespeicherter Stand deines gesamten Projekts, mit Datum, Namen und einer Notiz, was du geändert hast. Er bekommt eine Nummer wie a1b2c3d4e. Zu jedem Commit kannst du zurück.

Das Bild dazu: Du hast am Rezept gefeilt. Bevor du weitermachst, machst du ein Foto von der ganzen Seite und schreibst auf die Rückseite: „Zucker auf 80 g reduziert“. Das Foto ist der Commit. Die Bühne davor ist der Tisch, auf den du vorher genau die Zettel legst, die aufs Foto sollen.

git status
git add index.php
git commit -m "Tippfehler in der Startseite behoben"
git push

git status zeigt jederzeit, wo du stehst. Gewöhn ihn dir an – er ist der harmloseste Befehl von allen und beantwortet die meisten Fragen.

Merke: Ein Commit ist erst bei GitHub, wenn du git push getippt hast. Vorher lebt er nur auf deiner Festplatte. Und was du nie gepusht hast, kann auch niemand sehen.

07 · Branches: die Nebenspur

Ein Branch (Zweig) ist eine Nebenspur zum Ausprobieren. Du arbeitest daran, ohne den Hauptstand anzufassen. Geht es schief, wirfst du die Spur weg und nichts ist passiert. Der Hauptzweig heißt meist main, in älteren Projekten oft master.

Das Bild dazu: Du willst ein Rezept umbauen, traust dich aber nicht ans Kochbuch. Also legst du ein Extrablatt daneben und schreibst dort. Klappt es, heftest du das Blatt ins Buch ein. Klappt es nicht, zerknüllst du es – das Buch hat davon nie etwas gemerkt.

git checkout -b feature/mein-thema
git switch main

Der erste Befehl legt eine Nebenspur an und wechselt hinein. Der zweite geht zurück zum Hauptzweig. Deine Dateien im Ordner wechseln dabei mit – der Ordner zeigt immer den Stand der Spur, auf der du gerade stehst.

Eine Nebenspur zweigt vom Hauptzweig ab, sammelt eigene Commits und wird am Ende wieder eingefädelt. Bis dahin bleibt main unberührt und benutzbar.

08 · Mergen: wieder einfädeln

Mergen heißt zusammenführen: Die Commits deiner Nebenspur landen im Hauptzweig. Du stellst dich dafür erst auf die Spur, die etwas bekommen soll.

git switch main
git merge feature/mein-thema

Erst auf den Hauptzweig stellen, dann die Nebenspur hereinholen. Nie umgekehrt – sonst wandert der Hauptzweig in die Nebenspur.

Wenn seit dem Abzweigen niemand am Hauptzweig gearbeitet hat, schiebt Git den Zeiger einfach weiter. Das nennt sich Fast-Forward, es entsteht kein zusätzlicher Commit, und die Geschichte bleibt eine gerade Linie.

Ist die Spur vollständig eingefädelt, kannst du sie löschen. Die Commits sind ja im Hauptzweig – weg ist nur das Namensschild.

git branch -d feature/mein-thema

Das kleine -d ist die vorsichtige Variante: Git verweigert das Löschen, wenn die Spur noch nicht eingefädelt ist. -D löscht ohne Rückfrage – erst benutzen, wenn du sicher bist.

Merke: Vor jedem Löschen einer Spur lohnt eine Frage an Git: git branch --merged main listet alle Spuren, die wirklich schon im Hauptzweig stecken. Steht deine nicht dabei, würde Löschen Arbeit vernichten.

09 · Rebase: umsetzen statt zusammenführen

Es gibt zwei Arten, deine Spur mit einem weitergelaufenen Hauptzweig zu vereinen. Merge knotet beide zusammen und hinterlässt einen Verbindungs-Commit. Rebase nimmt deine Commits ab und setzt sie neu oben auf den aktuellen Stand – als hättest du eben erst angefangen.

Das Bild dazu: Dein Extrablatt hängt an Seite 12. Inzwischen hat der Verlag die Seiten 12 bis 20 neu gedruckt. Beim Merge klebst du dein altes Blatt an und notierst, wo es hingehört. Beim Rebase schreibst du es sauber neu ab – passend zur neuen Seite 20.

Beide Wege führen zum selben Dateistand. Merge erzählt, dass parallel gearbeitet wurde; Rebase erzählt eine gerade Geschichte. Welcher Weg gewünscht ist, legt das jeweilige Projekt fest – viele bevorzugen eine gerade Historie und damit Rebase.

git switch feature/mein-thema
git rebase main

Stell dich auf die Spur, die umgesetzt werden soll, und nenne das neue Fundament.

Die eine Rebase-Regel: Rebase schreibt die Geschichte um: Die Commits bekommen neue Nummern. Solange die Spur nur bei dir liegt, ist das harmlos. Hast du sie schon gepusht und jemand anderes arbeitet damit, ziehst du ihm den Boden weg. Faustregel: Rebase nur auf Spuren, die noch niemand außer dir hat.

10 · Den Fork aktuell halten

Das Team des Originals arbeitet weiter. Dein Fork merkt davon nichts – er bleibt auf dem Stand von damals stehen. Damit du nicht immer weiter zurückfällst, holst du dir den neuen Stand ab. Zwei Wege führen dahin.

Auf GitHub

Auf der Seite deines Forks gibt es einen Knopf Sync fork. Ein Klick, und deine Kopie im Regal ist wieder auf Stand. Danach holst du dir das auf den Rechner:

git pull

Holt vom Fork, was dort neu ist, und baut es in deinen aktuellen Zweig ein.

Direkt vom Original

Oder du holst am Fork vorbei, direkt von upstream – das ist der direktere Weg:

git fetch upstream
git switch main
git merge upstream/main

fetch lädt nur herunter und verändert deine Dateien noch nicht. Erst merge baut den neuen Stand ein. Deshalb ist fetch jederzeit gefahrlos.

Stolperstein: Der Sync fork-Knopf auf GitHub kann Dinge, die dein Kommandozeilen-Werkzeug manchmal nicht darf. Ändert eine neue Version des Originals etwas an den automatischen Abläufen unter .github/workflows/, verweigert GitHub den Upload, solange deine Zugangsberechtigung das nicht ausdrücklich erlaubt. Der Knopf im Browser läuft dann trotzdem durch.

11 · Der Pull Request

Bis hierher war alles deine eigene Sache. Ein Pull Request – kurz PR – ist der Moment, in dem du das Original fragst: „Wollt ihr meine Änderung haben?“

Das Bild dazu: Du gehst mit deinem verbesserten Rezept zum Verlag und fragst, ob es in die nächste Auflage darf. Die schauen drauf, fragen vielleicht nach, und irgendwann heften sie es ein – oder eben nicht. Ein PR ist genau das: eine Bitte samt Begründung, kein Zugriff.

Ein PR geht immer von einer Spur in deinem Fork zum Hauptzweig des Originals. Deshalb legt man dafür eine eigene Spur an, statt den eigenen main zu schicken.

git push -u origin feature/mein-thema

Lädt die Spur in deinen Fork hoch. Das -u merkt sich die Verbindung, danach genügt git push. GitHub bietet dir anschließend von selbst einen Knopf zum Anlegen des PR an.

Nimmt das Projekt den PR an, wird er gemerged. Oft als Squash-Merge: Alle deine Commits werden zu einem einzigen zusammengefasst. Dein Beitrag ist dann drin – aber unter einer neuen Nummer. Deswegen zeigt Git deine alten Commits danach manchmal noch als „nicht enthalten“ an, obwohl der Inhalt längst im Original steckt. git cherry vergleicht in solchen Fällen den Inhalt statt der Nummern und gibt die ehrlichere Antwort.

12 · Wenn es klemmt

Konflikt

Zwei Leute haben dieselbe Zeile geändert. Git kann nicht raten, welche gilt, und legt die Entscheidung dir vor. In der Datei stehen dann beide Fassungen zwischen Markierungen wie <<<<<<< und >>>>>>>. Du räumst das auf, löschst die Markierungen und meldest dich zurück:

git add <datei>
git rebase --continue

Beim Mergen entsprechend git commit. Und wenn dir alles zu bunt wird: git rebase --abort stellt den Zustand von vorher wieder her, als wäre nichts gewesen.

Ich habe etwas kaputt gemacht

Git vergisst erstaunlich wenig. Jeder Stand, auf dem du einmal standest, steht im Fahrtenbuch:

git reflog

Listet auf, wo dein Zweig überall war. Mit git reset --hard <nummer> springst du zu einem dieser Punkte zurück. Das rettet die meisten Unfälle.

Push abgelehnt

Steht dort etwas von rejected oder non-fast-forward, hat GitHub Commits, die dir fehlen. Erst holen, dann schicken: git pull, danach git push. Ein --force überschreibt zwar die fremden Commits – aber es löscht sie damit auch. Nur benutzen, wenn du genau weißt, wessen Arbeit dort verschwindet.

„detached HEAD“

Klingt dramatisch, heißt nur: Du stehst auf einem einzelnen Commit statt auf einem Zweig. Alles, was du hier committest, gehört zu keiner Spur und ist schwer wiederzufinden. Zurück kommst du mit git switch main.

13 · Spickzettel

Die Befehle, die im Alltag wirklich vorkommen.

14 · Der typische Ablauf

Zum Schluss ein vollständiger Durchlauf, so wie er bei einer Änderung typischerweise abläuft. Hier siehst du alle Bausteine im Zusammenspiel.

1. Den Draht zum Original legen – Dein Rechner kennt anfangs nur deinen Fork. Damit er neue Versionen des Originals holen kann, bekommt er einmalig die zweite Adresse.

git remote add upstream https://github.com/original-team/projekt.git
git fetch upstream

2. Den Hauptzweig nachziehen – Hast du auf dem Hauptzweig selbst nichts geändert, kann Git den Zeiger einfach weiterschieben (Fast-Forward).

git switch main
git merge upstream/main

3. Abzweigen und arbeiten – Für jede Änderung eine eigene Spur anlegen, dann ändern, vormerken und festhalten.

git switch -c feature/mein-thema
git add <datei>
git commit -m "Kurze Beschreibung der Änderung"

4. Die Spur umsetzen – Ist das Original inzwischen weitergelaufen, setzt Rebase deine Commits oben auf den frischen Hauptzweig.

git rebase main feature/mein-thema

5. Hochladen und Pull Request stellen – Erst jetzt geht überhaupt etwas ins Internet. Danach bietet GitHub den Knopf für den Pull Request an.

git push -u origin feature/mein-thema

6. Aufräumen – Nach dem Merge prüfen, dass der Inhalt der Spur wirklich im Hauptzweig steckt. Erst dann löschen – lokal und auf GitHub.

git cherry origin/main origin/<spur>
git branch -d <spur>
git push origin --delete <spur>

Das Muster dahinter: Nachziehen, abzweigen, arbeiten, einfädeln, hochladen, aufräumen. Dieser Kreis wiederholt sich bei jeder Änderung – bei einer Zeile genauso wie bei einem ganzen Modul. Alles andere auf dieser Seite sind Sonderfälle davon.

Tipp für öffentliche Forks: Behebst du eine Sicherheitslücke, sollten Commit-Nachrichten nicht verraten, wie man sie ausnutzt. Wer Nachrichten nachträglich ändert, prüft mit git diff, dass der Code dabei unverändert geblieben ist.

Die Namen original-team/projekt, dein-name/projekt und feature/mein-thema sind Platzhalter – ersetze sie durch die Werte deines Projekts. Der Hauptzweig heißt in den Beispielen main; in manchen Projekten heißt er master. Prüfe das vorher mit git branch -a.