Dans votre clone local de votre référentiel forked, vous pouvez append le référentiel GitHub original en tant que “distant”. (“Les télécommandes” sont comme les pseudonymes des URL des référentiels – l’ origin est un, par exemple.) Vous pouvez alors récupérer toutes les twigs de ce référentiel en amont et rebaser votre travail pour continuer à travailler sur la version amont. En termes de commandes qui pourraient ressembler à:

 # Add the remote, call it "upstream": git remote add upstream https://github.com/whoever/whatever.git # Fetch all the twigs of that remote into remote-tracking twigs, # such as upstream/master: git fetch upstream # Make sure that you're on your master branch: git checkout master # Rewrite your master branch so that any commits of yours that # aren't already in upstream/master are replayed on top of that # other branch: git rebase upstream/master 

Si vous ne souhaitez pas réécrire l’historique de votre twig principale (par exemple, parce que d’autres personnes l’ont clonée), vous devez remplacer la dernière commande par git merge upstream/master . Cependant, pour faire des demandes de tirage aussi propres que possible, il est probablement préférable de les rebaser.

Si vous avez rebasé votre twig sur upstream/master vous devrez peut-être forcer le push afin de le transférer dans votre propre référentiel forked sur GitHub. Vous feriez cela avec:

 git push -f origin master 

Il vous suffit d’utiliser le -f la première fois après avoir effectué un rebasage.

A partir de mai 2014, il est possible de mettre à jour un fork directement depuis GitHub. Cela fonctionne toujours à partir de septembre 2017, mais cela mènera à une histoire de commit sale.

1. Ouvrez votre fourche sur GitHub.
2. Cliquez sur Pull Requests .
3. Cliquez sur Nouvelle demande de tirage . Par défaut, GitHub comparera l’original avec votre fork, et rien ne devrait être comparé si vous n’avez apporté aucune modification.
4. Cliquez sur changer de base si vous voyez ce lien. Sinon, réglez manuellement la fourche de base sur votre fourche et la fourche sur le côté amont. Maintenant, GitHub comparera votre fork avec l’original, et vous devriez voir toutes les dernières modifications.
5. Créez une requête d'extraction et atsortingbuez un nom prévisible à votre demande d’extraction (par exemple, Update from original ).
6. Faites défiler la liste jusqu’à Fusionner la demande de tirage , mais ne cliquez sur rien pour le moment.

Maintenant, vous avez trois options, mais chacune mènera à un historique de validation moins que correct.

1. La valeur par défaut créera une validation de fusion laide.
2. Si vous cliquez sur le menu déroulant et choisissez “Squash and merge”, tous les commits entrants seront écrasés en un. C’est le plus souvent quelque chose que vous ne voulez pas.
3. Si vous cliquez sur Rebase et merge , tous les commits seront “avec” vous, les PR originaux seront liés à votre PR, et GitHub affichera. This branch is X commits ahead, Y commits behind .

Donc, oui, vous pouvez garder votre repository mis à jour avec son interface en amont en utilisant l’interface Web GitHub, mais cela saperait l’historique de vos engagements. Restez fidèle à la ligne de commande – c’est facile.

Voici le document officiel de GitHub sur la synchronisation d’un fork :

Synchroniser une fourche

La mise en place

Avant de pouvoir synchroniser, vous devez append une télécommande qui pointe vers le référentiel en amont. Vous avez peut-être fait cela lorsque vous avez créé un fork.

Conseil: La synchronisation de votre fork ne met à jour que votre copie locale du référentiel. il ne met pas à jour votre référentiel sur GitHub.

 $ git remote -v # List the current remotes origin https://github.com/user/repo.git (fetch) origin https://github.com/user/repo.git (push) $ git remote add upstream https://github.com/otheruser/repo.git # Set a new remote $ git remote -v # Verify new remote origin https://github.com/user/repo.git (fetch) origin https://github.com/user/repo.git (push) upstream https://github.com/otheruser/repo.git (fetch) upstream https://github.com/otheruser/repo.git (push) 

La synchronisation

Deux étapes sont nécessaires pour synchroniser votre référentiel avec l’amont: vous devez d’abord extraire de la télécommande, puis vous devez fusionner la twig souhaitée dans votre twig locale.

Aller chercher

La récupération depuis le référentiel distant apportera ses twigs et leurs commits respectifs. Ceux-ci sont stockés dans votre référentiel local sous des twigs spéciales.

 $ git fetch upstream # Grab the upstream remote's twigs remote: Counting objects: 75, done. remote: Compressing objects: 100% (53/53), done. remote: Total 62 (delta 27), reused 44 (delta 9) Unpacking objects: 100% (62/62), done. From https://github.com/otheruser/repo * [new branch] master -> upstream/master 

Nous avons maintenant la twig maître en amont stockée dans une twig locale, en amont / maître

 $ git branch -va # List all local and remote-tracking twigs * master a422352 My local commit remotes/origin/HEAD -> origin/master remotes/origin/master a422352 My local commit remotes/upstream/master 5fdff0f Some upstream commit 

Fusion

Maintenant que nous avons récupéré le référentiel en amont, nous souhaitons fusionner ses modifications dans notre twig locale. Cela va synchroniser cette twig avec l’amont, sans perdre nos changements locaux.

 $ git checkout master # Check out our local master branch Switched to branch 'master' $ git merge upstream/master # Merge upstream's master into our own Updating a422352..5fdff0f Fast-forward README | 9 ------- README.md | 7 ++++++ 2 files changed, 7 insertions(+), 9 deletions(-) delete mode 100644 README create mode 100644 README.md 

Si votre agence locale n’a pas de commits uniques, git effectuera plutôt une accélération rapide:

 $ git merge upstream/master Updating 34e91da..16c56ad Fast-forward README.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) 

Astuce: Si vous souhaitez mettre à jour votre référentiel sur GitHub, suivez les instructions ici

Un grand nombre de réponses finissent par déplacer votre commit une fois avant le repository parent. Cette réponse résume les étapes trouvées ici qui vont déplacer votre fork vers le même commit que le parent .

1. Changer de répertoire dans votre référentiel local.

   • Passer à la twig principale si vous n’êtes pas git checkout master

2. Ajouter le parent en tant que référentiel distant, git remote add upstream

3. Emettre git fetch upstream

4. Émettre git rebase upstream/master

   • A ce stade, vous vérifiez que cela valide ce qui sera fusionné en tapant git status

5. Émettre git push origin master

Pour plus d’informations sur ces commandes, reportez-vous à l’ étape 3 .

Depuis novembre 2013, une demande de fonctionnalité non officielle est ouverte avec GitHub pour leur demander d’append une méthode très simple et intuitive pour maintenir un fork local synchronisé avec l’amont:

https://github.com/isaacs/github/issues/121

Remarque: La demande de fonctionnalité n’étant pas officielle, il est également conseillé de contacter [email protected] pour append votre support à une fonctionnalité comme celle-ci. La demande de fonctionnalité non officielle ci-dessus pourrait être utilisée comme preuve de l’intérêt manifesté pour cette mise en œuvre.

Avant-propos: Votre fork est “l’origine” et le référentiel dont vous avez créé le fork est “en amont”.

Supposons que vous avez déjà cloné votre fork sur votre ordinateur avec une commande comme celle-ci:

 git clone [email protected]:your_name/project_name.git cd project_name 

Si cela est donné, vous devez continuer dans cet ordre:

1. Ajoutez le “upstream” à votre référentiel cloné (“origin”):

    git remote add upstream [email protected]:original_author/project_name.git 

2. Récupère les commits (et twigs) du “en amont”:

    git fetch upstream 

3. Passez à la twig “master” de votre fork (“origine”):

    git checkout master 

4. Stash les modifications de votre twig “master”:

    git stash 

5. Fusionner les modifications de la twig “maître” du “en amont” dans votre twig “maître” de votre “origine”:

    git merge upstream/master 

6. Résoudre les conflits de fusion le cas échéant et commettre votre fusion

    git commit -am "Merged from upstream" 

7. Poussez les modifications sur votre fourche

    git push 

8. Récupérez vos modifications cachées (le cas échéant)

    git stash pop 

9. Vous avez terminé! Toutes nos félicitations!

GitHub fournit également des instructions pour ce sujet: Synchroniser un fork

Si, comme moi, vous ne commettez jamais rien directement sur le master , ce que vous devriez vraiment faire, vous pouvez faire ce qui suit.

À partir du clone local de votre fork, créez votre télécommande en amont. Il vous suffit de le faire une fois:

 git remote add upstream https://github.com/whoever/whatever.git 

Ensuite, chaque fois que vous voulez rattraper la twig principale du référentiel en amont, vous devez:

 git checkout master git pull upstream master 

En supposant que vous n’avez jamais rien commis sur le maître, vous devriez déjà être fait. Vous pouvez maintenant envoyer votre maître local à votre fourche GitHub distante d’origine. Vous pouvez également modifier votre twig de développement sur votre maître local désormais à jour.

Donc, après la configuration initiale en amont et la vérification principale, il vous suffit d’exécuter la commande suivante pour synchroniser votre maître avec le maître en amont: git pull .

A la date de cette réponse, GitHub n’a pas ( ou ne doit-il plus dire? ) Cette fonctionnalité dans l’interface Web. Vous pouvez cependant demander à [email protected] d’append votre vote pour cela.

Entre-temps, l’utilisateur de GitHub, bardiharborow, a créé un outil pour cela: https://upriver.github.io/

La source est ici: https://github.com/upriver/upriver.github.io

Si vous utilisez GitHub pour Windows, ils disposent maintenant d’une fonctionnalité en un clic pour mettre à jour les forks:

1. Sélectionnez le référentiel dans l’interface utilisateur.
2. Cliquez sur le bouton “Mettre à jour depuis l’utilisateur / la twig” en haut.

Suivez les étapes ci-dessous. Je les ai essayés et cela m’a aidé.

Caisse à votre succursale

Syntaxe: git branch yourDevelopmentBranch
Exemple: git checkout master

Extraire la twig du référentiel source pour obtenir le dernier code

Syntaxe: git pull https://github.com/tastejs/awesome-app-ideas master
Exemple: git pull https://github.com/ORIGINAL_OWNER/ORIGINAL_REPO.git BRANCH_NAME

En fait, il est possible de créer une twig dans votre fork à partir de n’importe quel commit de l’amont dans le navigateur:

• Ouvrez https://github.com//commits/ , où repo est votre fork, et hash est un hachage complet de commit que vous pouvez trouver dans l’interface Web en amont. Par exemple, je peux ouvrir https://github.com/max630/linux/commits/0aa0313f9d576affd7747cc3f179feb097d28990 , qui indique que linux master le moment de l’écriture.
• Cliquez sur le bouton “Arbre: ….”.
• Tapez le nom de la nouvelle twig et appuyez sur Entrée

Vous pouvez ensuite récupérer cette twig sur votre clone local, et vous n’aurez pas à repousser toutes ces données vers GitHub lorsque vous apposerez des modifications sur ce dernier. Ou utilisez l’interface Web pour changer quelque chose dans cette twig.

Comment ça marche (c’est une supposition, je ne sais pas exactement comment GitHub le fait): les forks partagent le stockage des objects et utilisent les espaces de noms pour séparer les références des utilisateurs. Vous pouvez donc accéder à tous les commits via votre fourchette, même s’ils n’existaient pas au moment de la falsification.

Je mets à jour mes repos fourchus avec cette seule ligne:

 git pull https://github.com/forkuser/forkedrepo.git branch 

Utilisez cette option si vous ne souhaitez pas append un autre sharepoint terminaison distant à votre projet, comme les autres solutions affichées ici.

En complément de cette réponse, je cherchais un moyen de mettre à jour en une fois toutes les twigs distantes de mon repo ( origine ) cloné à partir de twigs en amont . C’est comme ça que je l’ai fait.

Cela suppose que vous ayez déjà configuré une télécommande en amont pointant vers le référentiel source (d’où l’ origine a été créée) et que vous l’avez synchronisée avec git fetch upstream .

Puis lancez:

 for branch in $(git ls-remote --heads upstream|sed 's#^.*refs/heads/##'); do git push origin refs/remotes/upstream/$branch:refs/heads/$branch; done 

La première partie de cette commande répertorie toutes les têtes du repo distant en amont et supprime le SHA-1 suivi du préfixe refs/heads/ branch name.

Ensuite, pour chacune de ces twigs, la copie locale de la twig de suivi distante en amont ( refs/remotes/upstream/ du côté local) est envoyée directement à la twig distante d’ origine ( refs/heads/ du côté distant). ).

Chacune de ces commandes de synchronisation de twig peut échouer pour l’une des deux raisons suivantes: soit la twig en amont a été réécrite, soit vous avez poussé des validations sur cette twig vers votre fork. Dans le premier cas où vous n’avez rien envoyé à la twig de votre fork, vous pouvez appuyer avec force (Ajouter le paramètre -f , par exemple, git push -f dans la commande ci-dessus). Dans le cas contraire, cela est normal car votre twig de fork a divergé et vous ne pouvez pas vous attendre à ce que la commande de synchronisation fonctionne jusqu’à ce que vos commits aient été fusionnés en amont .

Android Studio a maintenant appris à travailler avec les référentiels GitHub (vous n’avez même pas besoin d’append un repository distant “en amont” par commande de console).

Ouvrir le menu VCS → Git

Et faites attention aux deux derniers éléments du menu contextuel:

• Rebase ma fourche GitHub

• Créer une demande de tirage

Essayez les. J’utilise le premier pour synchroniser mon référentiel local. Quoi qu’il en soit, les twigs du repository distant parent («upstream») seront accessibles dans Android Studio après avoir cliqué sur «Rebase my GitHub fork», et vous pourrez les utiliser facilement.

(J’utilise Android Studio 3.0 avec les plugins “Git integration” et “GitHub”.)

Lorsque vous avez cloné votre référentiel forké, accédez au chemin de répertoire où réside votre clone et aux quelques lignes de votre terminal Git Bash.

 $ cd project-name $ git remote add upstream https://github.com/user-name/project-name.git # Adding the upstream -> the main repo with which you wanna sync $ git remote -v # you will see the upstream here $ git checkout master # see if you are already on master branch $ git fetch upstream 

Et là, vous êtes prêt à partir. Toutes les modifications mises à jour dans le référentiel principal seront introduites dans votre référentiel de fourches.

La commande “fetch” est indispensable pour restr à jour dans un projet: ce n’est que lorsque vous effectuez un “git fetch” que vous serez informé des modifications apscopes par vos collègues au serveur distant.

Vous pouvez toujours visiter ici pour d’autres questions

Cela dépend de la taille de votre référentiel et de la manière dont vous l’avez créé.

Si c’est un référentiel assez volumineux, vous avez peut-être voulu le gérer d’une manière particulière (par exemple, l’historique des drop). Fondamentalement, vous pouvez obtenir des différences entre les versions actuelles et les versions en amont, les valider et ensuite les ramener au maître.

Essayez de lire celui-ci . Il décrit comment gérer les référentiels Git volumineux et comment les faire évoluer avec les dernières modifications.