Tirez de nouvelles mises à jour du référentiel GitHub d'origine vers le référentiel GitHub bifurqué


615

J'ai bifurqué le référentiel de quelqu'un sur GitHub et je voudrais mettre à jour ma version avec des validations et des mises à jour effectuées dans le référentiel d'origine. Celles-ci ont été faites après avoir fourché ma copie.

Comment puis-je récupérer les modifications apportées à l'origine et les intégrer dans mon référentiel?


1
Duplicata possible, ou peut-être simplement lié: Fusion entre les fourches dans GitHub .

Dans le cas où il y aurait des balises supplémentaires que vous voudriez synchroniser, faites git push --force origin --tagsaprès les solutions proposées!
MediaVince

Réponses:


716

Vous devez ajouter le référentiel d'origine (celui que vous avez forké) en tant que télécommande.

Depuis la page de manuel de fork de GitHub :

fourchette

Une fois le clone terminé, votre dépôt aura une télécommande nommée " origin" qui pointe vers votre fork sur GitHub.
Ne laissez pas le nom vous dérouter, cela ne pointe pas vers le référentiel d'origine que vous avez créé. Pour vous aider à garder une trace de ce dépôt, nous ajouterons une autre télécommande nommée «en amont»:

$ cd github-services
$ git remote add upstream git://github.com/pjhyett/github-services.git
$ git fetch upstream

# then: (like "git pull" which is fetch + merge)
$ git merge upstream/master master

# or, better, replay your local work on top of the fetched branch
# like a "git pull --rebase"
$ git rebase upstream/master

Vous avez également une gemme rubis qui peut faciliter ces opérations GitHub .

à bifurcation

Voir aussi " Git fork is git clone? ".



2
@syedrakib Je préfère un git rebase upstream/master, mais j'ai ajouté les deux possibilités dans la réponse.
VonC

1
@PaBLoX si vous avez bifurqué un repo, vous travaillez sur votre repo, dans votre branche: rebase et force un push: pas de gâchis. Même une pull request en cours serait correctement mise à jour.
VonC

2
@PaBLoX vous ne créez pas de gâchis: vous git push --force, en remplaçant l'historique de votre branche sur GitHub par votre branche locale que vous venez de rebaser. Puisque seul vous utilisez une branche triste, aucun désordre n'est impliqué.
VonC

2
Je comprends. Je pense toujours que c'est difficile, non trivial et non intuitif. C'est toujours bizarre que mes changements soient toujours au top (dernier), alors qu'en réalité ils ont été faits avant. La solution que j'ai postée avant semble meilleure (toujours aussi non triviale). Le problème est que la validation des hachages change (évidemment, car il y a un nouveau parent) et génère beaucoup de bruit à l'intérieur de github lorsque des problèmes sont appelés. Cela me surprend toujours qu'il n'y ait aucun moyen de rester à jour avec l'amont et de gérer votre propre fork sans créer de commits de fusion inutiles ou "mentir" sur l'historique.
Pablo Olmos de Aguilera C.12

99

En plus de la réponse de VonC, vous pouvez la modifier encore plus à votre guise.

Après avoir récupéré à partir de la branche distante, vous devrez toujours fusionner les validations. Je remplacerais

$ git fetch upstream

avec

$ git pull upstream master

puisque git pull est essentiellement git fetch + git merge.


Que se passe-t-il si je sais que la branche en amont n'a aucune modification des fichiers existants, mais seulement quelques fichiers de ressources ajoutés - ai-je encore besoin de fusionner?
azec-pdx

4
Il fera sûrement une avance rapide dans ce cas
Domness

comment faire pour que le maître en amont écrase tous les fichiers locaux (donc pas de conflits de fusion) le maître en amont mène dans le code dans ce cas donc nous lui faisons confiance à 100% ... avons réussi à le faire
snh_nl

1
@snh_nl git rebase upstream masterNotez que ce n'est pas sans conflit si vous en avez suffisamment divergé upstream/master. Voir git-scm.com/docs/git-rebase (tl; dr: ce disque réinitialise votre maître local à celui de l'amont, puis essaie de faire disparaître tous les commits locaux du point de divergence)
cowbert

68

Cette vidéo montre comment mettre à jour un fork directement depuis GitHub

Pas:

  1. Ouvrez votre fourchette sur GitHub.
  2. Cliquez sur Pull Requests.
  3. Cliquez sur New Pull Request. Par défaut, GitHub comparera l'original avec votre fork, et il ne devrait y avoir rien à comparer si vous n'avez apporté aucune modification.
  4. Cliquez sur switching the base. Maintenant, GitHub comparera votre fork avec l'original, et vous devriez voir toutes les dernières modifications.
  5. Cliquez sur Create a pull requestpour cette comparaison et attribuez un nom prévisible à votre demande d'extraction (par exemple, Mettre à jour à partir de l'original).
  6. Cliquez sur Create pull request.
  7. Faites défiler vers le bas et cliquez Merge pull requestet enfin Confirmfusionnez. Si votre fork n'a subi aucun changement, vous pourrez le fusionner automatiquement.

3
Malheureusement, cette belle méthode graphique crée du bruit supplémentaire dans votre fork comme mentionné ci-dessus dans les commentaires pour la réponse acceptée. Par conséquent, la méthode de ligne de commande est recommandée: help.github.com/articles/syncing-a-fork
Jonathan Cross

Je ne pouvais pas trouver l' switching the baseoption
Alper

64

Utilisation:

git remote add upstream ORIGINAL_REPOSITORY_URL

Cela placera votre amont vers le référentiel à partir duquel vous avez effectué un fork. Ensuite, faites ceci:

git fetch upstream      

Cela récupérera toutes les branches, y compris master du référentiel d'origine.

Fusionnez ces données dans votre branche principale locale:

git merge upstream/master

Poussez les modifications dans votre référentiel forké, c'est-à-dire vers l'origine:

git push origin master

Voila! Vous avez terminé la synchronisation du référentiel d'origine.


comment faire pour que le maître en amont écrase tous les fichiers locaux (donc pas de conflits de fusion) le maître en amont mène dans le code dans ce cas donc nous lui faisons confiance à 100% ... avons réussi à le faire
snh_nl

Une façon consiste simplement à supprimer la copie locale et à effectuer un nouveau clonage :)
ARK

1

Si vous utilisez l'application de bureau GitHub, il y a un bouton de synchronisation dans le coin supérieur droit. Cliquez dessus puis en Update from <original repo>haut à gauche.

S'il n'y a pas de modifications à synchroniser, ce sera inactif.

Voici quelques captures d' écran pour vous faciliter la tâche.


1

S'il n'y a rien à perdre, vous pouvez également supprimer votre fourche, allez simplement dans les paramètres ... allez dans la section zone de danger ci-dessous et cliquez sur supprimer le référentiel. Il vous demandera de saisir le nom du référentiel et votre mot de passe après. Après cela, il vous suffit de refaire l'original.


1

Si vous voulez le faire sans cli, vous pouvez le faire entièrement sur le site Web de Github.

  1. Accédez à votre référentiel fork.
  2. Cliquez sur New pull request.
  3. Assurez-vous de définir votre fork comme référentiel de base et le référentiel d'origine (en amont) comme référentiel principal. Habituellement, vous souhaitez uniquement synchroniser la branche principale.
  4. Create new pull request.
  5. Sélectionnez la flèche à droite du bouton de fusion et assurez-vous de choisir rebaser au lieu de fusionner. Cliquez ensuite sur le bouton. De cette façon, il ne produira pas de validation de fusion inutile.
  6. Terminé.

0

Pour synchroniser automatiquement votre référentiel forké avec le référentiel parent, vous pouvez utiliser l' application Pull sur GitHub.

Reportez-vous au fichier Lisezmoi pour plus de détails.

Pour une configuration avancée où vous souhaitez conserver vos modifications apportées au référentiel forké, reportez-vous à ma réponse sur une question similaire ici .

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.