Fork synchroniseren met upstream: 3 veilige methodes

TL;DR: draai git fetch upstream && git merge upstream/main && git push origin main en je fork is bij. Dat is de hele fork-synchronisatie-workflow in één regel — haal de wijzigingen op van het project dat je forkte en push ze naar je kopie. Liever lineaire history, vervang merge door git rebase upstream/main en force-push. En heb je de upstream-remote überhaupt nooit aangelegd, begin dan bij stap 1 hieronder, want die ontbrekende remote is reden nummer één dat een fork “niet synchroniseert”. Al het andere — rebasen, de sync-knop van GitHub, niet-pushbare diverged branches — is detail bovenop die drie commando’s.

Wat betekent het om een fork met upstream te synchroniseren?

Een fork is je kopie van het repository van iemand anders op GitHub. Het origineel is de upstream; jouw kopie is de origin. GitHub-forks werken zichzelf niet bij — als de maintainers een pull request mergen, houdt jouw kopie de code van gisteren. Een fork synchroniseren betekent de nieuwe upstream-commits in je fork trekken zodat je branch overeenkomt met — of ten minste bevat — de huidige stand van het project.

Dit is om twee redenen belangrijk. Ten eerste bijdragen: elk pull request dat je vanaf een achterstallige fork opent heeft extra ruis, en maintainers vragen je bij te werken vóór de merge. Ten tweede self-hosten of bestuderen: draai je een fork in productie of lees je alleen de code, dan is een fork van een maand oud een maand aan bugfixes die je niet hebt.

Hoe synchroniseer ik een fork met upstream vanaf de command line?

Drie stappen: declareer de upstream één keer, fetch van hem, merge en push. De bedrading is permanent — stap 2 en 3 zijn alles wat je de volgende keer typt.

Stap 1 — voeg de upstream-remote toe (eenmalig per clone).

# inside your local clone of the fork
git remote add upstream https://github.com/ORIGINAL_OWNER/REPO.git
git remote -v   # confirm: origin -> your fork, upstream -> the original

Zoek de juiste URL op de pagina van het originele repo: de groene Code-knop. Een veelgemaakte fout is beide remotes op je eigen fork te richten — dan doet een sync stil niets, want je fetchte van een kopie die net zo achterstallig was als degene die je al had.

Stap 2 — fetch en merge de upstream-branch.

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

Dat is het standaardantwoord op de commandline-sync van een fork. Een fast-forward is de normale uitkomst — main op je fork had niets nieuws, dus hij schuift gewoon vooruit naar upstream/main en er ontstaat geen merge-commit.

Stap 3 — herhaal op verzoek. Er is niets te onthouden behalve git fetch upstream && git merge upstream/main && git push origin main. Wil je vóór het mergen weten hoeveel je achterloopt, draai dan na de fetch git rev-list --count main..upstream/main.

Moet ik rebasen of mergen bij het synchroniseren van een fork?

Beide laten dezelfde code in je fork achter; ze verschillen in de history die ze nalaten. Kies één beleid per repo en houd dat vast:

Methode	Commando	History-resultaat	Best voor
Merge	git merge upstream/main	Extra merge-commit op diverged branches	Feature-branches met open PR’s — herschrijft nooit iets
Rebase	git rebase upstream/main	Je commits opnieuw afgespeeld, lineaire history	De main van je fork schoon houden; diverged forks resetten
GitHub UI	Sync-branch-knop / PR-merge	Zelfde als merge	Snel bijwerken zonder open clone

De rebase-variant van de sync:

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

De force-push is nodig omdat rebasen commit-ID’s herschrijft — de remote-branch van je fork stamt niet meer af van je lokale. Kies altijd --force-with-lease boven --force: hij weigert de remote te overschrijven als er intussen iemand (of een andere machine van jou) gepusht heeft, wat het gevaarlijke commando standaard veilig maakt.

Eén regel om op je pols te tatoeëren: rebase nooit een branch met een open pull request tenzij je weet wat je doet — rebasen verandert commit-ID’s, wat een open PR van zijn commits kan loskoppelen. Sync main met merge (of rebase hem vóór je nieuw werk start) en houd PR-branches erbuiten.

Waarom synchroniseert mijn fork niet met upstream?

De vier gebruikelijke verdachten, in de volgorde waarin ze in echte terminals opduiken:

1. Geen upstream-remote — git remote -v toont alleen origin. Symptoom: git fetch upstream faalt met 'upstream' does not appear to be a git repository. Fix: stap 1 hierboven.
2. Gefetcht maar nooit gemerged — fetchen werkt upstream/main bij in je lokale repo maar raakt geen werkende branch. Symptoom: git log ziet er oud uit na een geslaagde fetch. Fix: git merge upstream/main.
3. Diverged history — je committe op de main van je fork, en upstream bewoog ook. git pull klaagt dan over unrelated histories of forceert een merge. Fix, als upstream moet winnen: git reset --hard upstream/main (gooit je lokale alleen-op-main-commits weg — check eerst git stash list of maak een backup-branch; is er al een foute reset gebeurd, dan is het herstelpad hetzelfde als bij de laatste commit ongedaan maken: git reflog kent de oude tip nog).
4. Push afgewezen als non-fast-forward na een rebase — je rebasde maar pushte normaal. Fix: git push --force-with-lease origin main.

Een vijfde, zeldzaam geval: het upstream-repo is hernoemd of verwijderd, zodat zelfs de URL uit stap 1 een 404 geeft. GitHub leidt hernoemde repo’s om, dus een harde mislukking betekent meestal verwijderd of private geworden — er is niets meer om mee te synchroniseren.

Kun je een fork vanaf de GitHub-website synchroniseren?

Ja. Op de pagina van je fork toont de branch-dropdown een Sync fork-knop zodra je branch achterloopt; één klik trekt upstream naar binnen. Daaronder werkt hetzelfde via een pull request: open een PR van upstream/main naar de main van je fork en merge hem.

De grenzen van de knop bepalen wanneer je terugvalt op de CLI: hij doet alleen fast-forward of merge — rebasen kan niet, en bij diverged branches weigert hij ronduit met de melding commits weg te gooien of de command line te gebruiken. Ook synchroniseert hij alleen de default branch. Voor alles voorbij een simpele bijwerkronde zijn de drie commando’s hierboven het gereedschap.

Hoe vaak synchroniseer je je fork?

Vóór elk nieuw stuk werk is het eerlijke antwoord: branch af van een verse main, en geen PR die je opent begint met “dit is gebaseerd op een versie van drie weken geleden”. Voor forks waar je actief aan bijdraagt kost een dagelijkse of per-sessie sync van main seconden. Voor een fork die je alleen leest of deployed: sync zodra upstream iets oplevert dat je wilt — abonneer je op de releases-feed van het originele repo en sync bij een release. Synchroniseren is goedkoop juist omdat het routine is; een fork van zes maanden achter heeft vaak chirurgie nodig in plaats van een merge, en zo wordt sync-mijn-fork een middag.

Cheatsheet

# one-time setup
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, linear history)
git fetch upstream && git rebase upstream/main && git push --force-with-lease origin main

# how far behind am I?
git fetch upstream && git rev-list --count main..upstream/main

# diverged beyond repair — make main identical to upstream (destructive)
git fetch upstream && git reset --hard upstream/main && git push --force-with-lease origin main

Houd de routine-tweeliner in je spiergeheugen en een diverged fork blijft een curiositeit die je leest in plaats van een probleem dat je fixt. Strekt je git-huishouding zich uit tot servers, dan behandelt de journalctl-cheatsheet de andere helft van het leesbaar houden van de history van een machine.