Git-Fork mit Upstream syncen: 3 sichere Methoden

TL;DR: git fetch upstream && git merge upstream/main && git push origin main — und dein Fork ist auf dem Stand. Das ist der komplette Workflow „git sync fork with upstream” in einer Zeile: Änderungen aus dem Projekt, das du geforkt hast, ziehen, dann auf deine Kopie pushen. Willst du lineare History, tausch merge gegen git rebase upstream/main und force-push. Und falls du das upstream-Remote überhaupt noch nie eingerichtet hast, fang mit Schritt 1 unten an — dieses fehlende Remote ist der Grund Nummer eins, warum ein Fork „nicht synchronisiert”. Alles andere — Rebasing, der GitHub-Sync-Button, auseinanderlaufende Branches, die sich nicht pushen lassen — ist Detail auf diesen drei Befehlen.

Was bedeutet es, einen Fork mit dem Upstream zu syncen?

Ein Fork ist deine Kopie des Repositorys von jemand anderem auf GitHub. Das Original ist der Upstream, deine Kopie ist Origin. GitHub-Forks aktualisieren sich nicht selbst — wenn die Maintainer einen Pull Request mergen, behält deine Kopie den Code von gestern. Einen Fork zu syncen heißt, die neuen Commits des Upstreams in deinen Fork zu ziehen, damit dein Branch dem aktuellen Stand des Projekts entspricht oder ihn zumindest enthält.

Das zählt aus zwei Gründen. Erstens Beiträge: Jeder Pull Request von einem veralteten Fork trägt zusätzlichen Ballast mit sich, und Maintainer bitten dich vor dem Merge um ein Update. Zweitens Self-Hosting oder Studium: Betreibst du einen Fork im Produktivbetrieb oder liest nur den Code, ist ein ein Monat alter Fork ein Monat an Bugfixes, die du nicht hast.

Wie sync ich einen Fork mit dem Upstream in der Kommandozeile?

Drei Schritte: Den Upstream einmal deklarieren, von ihm fetchen, dann mergen und pushen. Die Verkabelung bleibt bestehen — Schritt 2 und 3 sind alles, was du nächstes Mal tippst.

Schritt 1 — das Upstream-Remote hinzufügen (einmal pro Clone).

# in deinem lokalen Clone des Forks
git remote add upstream https://github.com/ORIGINAL_OWNER/REPO.git
git remote -v   # prüfen: origin -> dein Fork, upstream -> das Original

Die richtige URL findest du auf der Seite des Original-Repos: beim grünen Code-Button. Ein häufiger Fehler ist, beide Remotes auf deinen Fork zeigen zu lassen — dann macht ein „Sync” still nichts, weil du aus einer Kopie gefetcht hast, die genauso veraltet war wie deine.

Schritt 2 — den Upstream-Branch fetchen und mergen.

git checkout main
git fetch upstream
git merge upstream/main
git push origin main

Das ist die Standard-Antwort auf „git sync fork with upstream command line”. Ein Fast-Forward ist der Normalfall — main auf deinem Fork hatte nichts Neues, also gleitet es einfach nach vorn auf upstream/main, ohne dass ein Merge-Commit entsteht.

Schritt 3 — bei Bedarf wiederholen. Es gibt nichts zu merken außer git fetch upstream && git merge upstream/main && git push origin main. Willst du vor dem Merge sehen, wie weit hinten du bist, läuft nach dem Fetch git rev-list --count main..upstream/main.

Solltest du beim Syncen eines Forks rebasen oder mergen?

Beide Wege landen denselben Code in deinem Fork; sie unterscheiden sich in der History, die sie hinterlassen. Wähle eine Policy pro Repo und bleib dabei:

Methode	Befehl	Ergebnis in der History	Am besten für
Merge	git merge upstream/main	Zusätzlicher Merge-Commit bei abweichenden Branches	Feature-Branches mit offenen PRs — schreibt nie etwas um
Rebase	git rebase upstream/main	Deine Commits oben drauf gespielt, lineare History	Sauberes main im Fork; abweichende Forks, die du zurücksetzen willst
GitHub-UI	Sync-Branch-Button / PR-Merge	Wie Merge	Schnelles Nachziehen ohne offenen Clone

Die Rebase-Variante des Syncs:

git fetch upstream
git rebase upstream/main
git push --force-with-lease origin main

Der Force-Push ist nötig, weil ein Rebase Commit-IDs umschreibt — der Remote-Branch deines Forks stammt nicht mehr von deinem lokalen ab. Zieh --force-with-lease immer --force vor: Es verweigert das Überschreiben des Remotes, wenn jemand (oder eine deiner anderen Maschinen) zwischendurch gepusht hat — das macht den gefährlichen Befehl zur sicheren Standardeinstellung.

Eine Regel, die man sich auf den Handrücken tätowieren sollte: Rebase nie einen Branch mit offenem Pull Request, außer du weißt genau, was du tust — Rebasing ändert Commit-IDs und kann einen offenen PR von seinen Commits abkoppeln. Sync main per Merge (oder rebase ihn, bevor du neue Arbeit startest) und lass PR-Branches daraus raus.

Warum synchronisiert mein Fork nicht mit dem Upstream?

Die vier üblichen Verdächtigen, in der Reihenfolge, in der sie in echten Terminals auftauchen:

1. Kein upstream-Remote — git remote -v zeigt nur origin. Symptom: git fetch upstream schlägt fehl mit 'upstream' does not appear to be a git repository. Fix: Schritt 1 oben.
2. Gefetcht, aber nie gemergt — Fetchen aktualisiert upstream/main in deinem lokalen Repo, rührt aber keinen Arbeits-Branch an. Symptom: git log sieht nach erfolgreichem Fetch alt aus. Fix: git merge upstream/main.
3. Abweichende History — du hast auf dem main deines Forks committet, und der Upstream ist auch weitergezogen. git pull mault dann über unrelated histories oder erzwingt einen Merge. Fix, wenn der Upstream gewinnen soll: git reset --hard upstream/main (wirft deine lokalen main-only-Commits weg — vorher git stash list prüfen oder per Branch sichern; ist der schlechte Reset schon passiert, ist der Rettungsweg derselbe wie bei git letzten Commit rückgängig machen: git reflog kennt die alte Spitze noch).
4. Push abgelehnt als Non-Fast-Forward nach einem Rebase — du hast rebased, aber normal gepusht. Fix: git push --force-with-lease origin main.

Ein fünfter, seltener Fall: Das Upstream-Repo wurde umbenannt oder gelöscht, und selbst die URL aus Schritt 1 liefert 404. GitHub leitet umbenannte Repos weiter — ein harter Fehler heißt meist gelöscht oder auf privat gestellt. Dann gibt es nichts mehr, wohin man syncen könnte.

Kann man einen Fork über die GitHub-Website syncen?

Ja. Auf der Seite deines Forks zeigt der Branch-Dropdown einen Sync fork-Button, sobald dein Branch hinten dranhängt; ein Klick zieht den Upstream rein. Darunter funktioniert dasselbe als Pull Request: von upstream/main auf das main deines Forks einen PR öffnen und mergen.

Die Grenzen des Buttons erklären, wann du zur CLI zurückkehrst: Er macht nur Fast-Forward oder Merge — rebasen tut er nicht, und bei abweichenden Branches verweigert er komplett den Dienst und verweist dich aufs Verwerfen von Commits oder die Kommandozeile. Er synchronisiert außerdem nur den Default-Branch. Für alles über ein einfaches Nachziehen hinaus sind die drei Befehle von oben das Werkzeug.

Wie oft solltest du deinen Fork syncen?

Vor jeder neuen Arbeit ist die ehrliche Antwort: Von einem frischen main abzweigen, und kein PR, den du öffnest, beginnt mit „basiert auf einer Version von vor drei Wochen”. Für Forks, zu denen du aktiv beiträgst, kostet ein täglicher oder sessionweiser Sync von main Sekunden. Für einen Fork, den du nur liest oder deployst: syncen, wenn der Upstream etwas liefert, das du willst — abonniere den Releases-Feed des Original-Repos und sync bei jedem Release. Syncen ist billig gerade, weil es Routine ist; ein Fork mit sechs Monaten Rückstand braucht oft eine Operation statt eines Merges — so wird aus „sync my fork” schon mal ein Nachmittag.

Spickzettel

# einmalige Einrichtung
git remote add upstream https://github.com/ORIGINAL_OWNER/REPO.git

# Routine-Sync (Merge-Policy)
git fetch upstream && git merge upstream/main && git push origin main

# Routine-Sync (Rebase-Policy, lineare History)
git fetch upstream && git rebase upstream/main && git push --force-with-lease origin main

# wie weit hinten bin ich?
git fetch upstream && git rev-list --count main..upstream/main

# abweichend ohne Rettung — main identisch mit dem Upstream machen (destruktiv)
git fetch upstream && git reset --hard upstream/main && git push --force-with-lease origin main

Hältst du den Routine-Zweizeiler im Muskelgedächtnis, bleibt der abweichende Fork eine Kuriosität, über die man liest, und wird kein Problem, das man fixt. Wenn deine Git-Haushaltsführung bis auf Server reicht, deckt der journalctl-Spickzettel die andere Hälfte davon ab, die History einer Maschine lesbar zu halten.