Synchroniser un fork avec l'amont — trois méthodes sûres

■ space · voie prose

LE PIPELINE

Une synchro voyage toujours dans un sens — upstream → votre main local → origin. Rien du fork ne remonte vers l'upstream ; c'est à ça que servent les pull requests.

origin = votre fork · upstream = le projet que vous avez forké — l'erreur courante est de pointer les deux remotes sur votre fork ; alors une « synchro » ne fait tranquillement rien, parce que vous avez fetch depuis une copie tout aussi périmée que la vôtre

ÉTAPE 1 — CÂBLER LE REMOTE (UNE FOIS PAR CLONE)

# dans votre clone local du fork
git remote add upstream https://github.com/ORIGINAL_OWNER/REPO.git
git remote -v   # confirmer : origin -> votre fork, upstream -> l'original

Trouvez l'URL correcte sur la page du dépôt original, sous le bouton vert Code. Ce câblage est permanent — tout ce qui suit, c'est ce que vous tapez la prochaine fois.

ÉTAPE 2 — FETCH, MERGE, PUSH

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

vérifiez : git rev-list --count main..upstream/main → 12 avant le merge → 0 après

Un fast-forward est l'issue normale — votre main n'avait rien de neuf, il glisse simplement vers l'avant jusqu'à upstream/main et aucun commit de merge n'est créé. Pour voir votre retard avant de merger : git rev-list --count main..upstream/main après le fetch. C'est toute la routine ; l'étape 3, c'est de se rappeler qu'elle existe : git fetch upstream && git merge upstream/main && git push origin main.

MERGE OU REBASE ?

Les deux font atterrir le même code dans votre fork ; ils diffèrent par l'histoire qu'ils laissent derrière eux. Choisissez une politique par dépôt et tenez-y-vous :

# la variante rebase, histoire linéaire :
git fetch upstream
git rebase upstream/main
git push --force-with-lease origin main

Le force push est requis parce que le rebase réécrit les IDs de commits — la branche distante de votre fork ne descend plus de la locale. Préférez toujours --force-with-lease à --force : il refuse d'écraser le distant si quelqu'un (ou une autre de vos machines) a poussé entre-temps, ce qui rend la commande dangereuse sûre par défaut. Et la règle d'or : never rebase a branch that has an open pull request unless you know what you are doing — le rebase change les IDs de commits, ce qui peut détacher une PR ouverte de ses commits. Synchronisez main avec merge, gardez les branches de PR hors de ça.

« MON FORK NE SE SYNCHRONISE PAS » — LES QUATRE SUSPECTS HABITUELS

1. Pas de remote upstream : — git remote -v ne montre que origin. Symptôme : git fetch upstream fails with échoue avec 'upstream' does not appear to be a git repository
. Solution : étape 1.
2. Fetché mais jamais mergé — le fetch met à jour upstream/main localement mais ne touche aucune branche de travail. Symptôme : git log a l'air vieux après un fetch réussi. Solution : git merge upstream/main.
3. Histoire divergée — you committed to your fork's et l'upstream a bougé aussi. Solution, si vous voulez que l'upstream gagne : and upstream moved too. Fix, if you want upstream to win: git reset --hard upstream/main — ça jette vos commits propres à votre main local, alors sauvegardez-les d'abord dans une branche ; si un mauvais reset a déjà eu lieu, git reflog connaît toujours la vieille pointe.
4. Push rejeté en non-fast-forward après un rebase — you rebased but pushed normally. Fix: . Solution : .

Un cinquième cas, rare : le dépôt upstream a été renommé ou supprimé, si bien que même l'URL de l'étape 1 fait un 404. GitHub redirige les dépôts renommés, donc un échec dur signifie en général supprimé ou rendu privé — plus rien à quoi se synchroniser.

LE BOUTON

Oui, le site web peut le faire : sur la page de votre fork, le menu déroulant de branche montre un bouton Sync forkSync fork dès que votre branche est en retard ; un clic tire l'upstream. En dessous, la même chose marche comme une pull request de into your fork's main. Les limites du bouton expliquent quand revenir au CLI : il ne fait qu'un fast-forward ou un merge — il ne rebase pas, et il refuse carrément quand les branches ont divergé, en vous disant d'abandonner les commits ou de passer en ligne de commande. Il ne synchronise aussi que la branche par défaut. Pour tout ce qui dépasse un simple rattrapage, les trois commandes sont l'outil.

À QUELLE FRÉQUENCE ?

Avant chaque nouveau morceau de travail, c'est la réponse honnête : branchez depuis un main frais, et aucune PR que vous ouvrez ne commence par « ceci est basé sur une version d'il y a trois semaines ». Pour les forks auxquels vous contribuez activement, une synchro quotidienne ou par session de main coûte des secondes. Pour un fork que vous ne faites que lire ou déployer, synchronisez quand l'upstream livre quelque chose que vous voulez — abonnez-vous au flux des releases du dépôt original et synchronisez à la sortie. La synchro est bon marché justement parce que c'est une routine ; un fork en retard de six mois a souvent besoin de chirurgie plutôt que d'un merge, et c'est ainsi que « synchronise mon fork » devient un après-midi.

08L'ANTISÈCHE

# configuration une fois pour toutes
git remote add upstream https://github.com/ORIGINAL_OWNER/REPO.git

# synchro de routine (politique merge)
git fetch upstream && git merge upstream/main && git push origin main

# synchro de routine (politique rebase, histoire linéaire)
git fetch upstream && git rebase upstream/main && git push --force-with-lease origin main

# de combien suis-je en retard ?
git fetch upstream && git rev-list --count main..upstream/main

# divergé au-delà de toute réparation — rendre main identique à l'upstream (destructif)
git fetch upstream && git reset --hard upstream/main && git push --force-with-lease origin main

Gardez la routine à deux lignes dans votre mémoire musculaire et le fork divergé reste une curiosité qu'on lit, pas un problème qu'on répare.

fin de la page synchro · rien de récupéré · tout est local