J'ai récemment créé un projet et appliqué plusieurs correctifs. J'ai ensuite créé une demande de tirage qui a ensuite été acceptée.

Quelques jours plus tard, une autre modification a été apportée par un autre contributeur. Donc, ma fourchette ne contient pas ce changement.

Comment puis-je mettre ce changement dans ma fourchette? Dois-je supprimer et recréer ma fourchette lorsque j'ai d'autres modifications à apporter? Ou existe-t-il un bouton de mise à jour?

Dans votre clone local de votre référentiel forké, vous pouvez ajouter le référentiel GitHub d'origine en tant que "distant". (Les "télécommandes" sont comme des surnoms pour les URL des référentiels - originpar exemple.) Ensuite, vous pouvez récupérer toutes les branches de ce référentiel en amont et rebaser votre travail pour continuer à travailler sur la version en 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 branches of that remote into remote-tracking branches,
# 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 voulez pas réécrire l'historique de votre branche principale (par exemple parce que d'autres personnes l'ont peut-être clonée), vous devez remplacer la dernière commande par git merge upstream/master. Cependant, pour effectuer d'autres requêtes d'extraction aussi propres que possible, il est probablement préférable de rebaser.

Si vous avez rebasé votre branche sur, upstream/mastervous devrez peut-être forcer le push pour le pousser vers votre propre référentiel forké sur GitHub. Vous feriez cela avec:

git push -f origin master

Vous ne devez l'utiliser que -fla première fois après avoir rebasé.

À partir de mai 2014, il est possible de mettre à jour un fork directement depuis GitHub. Cela fonctionne toujours depuis septembre 2017, MAIS cela conduira à un sale historique de commit.

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 switching the basesi vous voyez ce lien. Sinon, définissez manuellement la liste base forkdéroulante sur votre fourche et head forksur en amont. Maintenant, GitHub comparera votre fork avec l'original, et vous devriez voir toutes les dernières modifications.
5. Create pull requestet attribuez un nom prévisible à votre demande d'extraction (par exemple, Update from original).
6. Faites défiler la page jusqu'à Merge pull request, mais ne cliquez sur rien encore.

Vous avez maintenant trois options, mais chacune mènera à un historique de commit moins que net.

1. La valeur par défaut créera un vilain commit de fusion.
2. Si vous cliquez sur le menu déroulant et choisissez "Squash and merge", tous les validations intermédiaires seront écrasées en une seule. C'est le plus souvent quelque chose que vous ne voulez pas.
3. Si vous cliquez Rebase and merge, toutes les validations seront effectuées "avec" vous, les PR d'origine seront liés à votre PR et GitHub s'affichera This branch is X commits ahead, Y commits behind <original fork>.

Donc oui, vous pouvez garder votre dépôt à jour avec son amont en utilisant l'interface utilisateur Web de GitHub, mais cela endommagera votre historique de validation. Restez à la ligne de commande à la place - c'est facile.

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

Synchronisation d'une fourchette

La mise en place

Avant de pouvoir synchroniser, vous devez ajouter une télécommande qui pointe vers le référentiel en amont. Vous l'avez peut-être fait lors de votre fork d'origine.

Astuce: La synchronisation de votre fork met uniquement à jour 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)

Synchronisation

Il y a deux étapes requises pour synchroniser votre référentiel avec l'amont: vous devez d'abord extraire de la télécommande, puis vous devez fusionner la branche souhaitée dans votre branche locale.

Aller chercher

La récupération à partir du référentiel distant apportera ses branches et leurs validations respectives. Ceux-ci sont stockés dans votre référentiel local sous des branches spéciales.

$ git fetch upstream
# Grab the upstream remote's branches
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 branche maître en amont stockée dans une branche locale, en amont / maître

$ git branch -va
# List all local and remote-tracking branches
* 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 voulons fusionner ses modifications dans notre branche locale. Cela permettra à cette branche de se synchroniser 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 branche locale n'a pas eu de commit unique, git effectuera à la place une "avance rapide":

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

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

De nombreuses réponses finissent par déplacer votre fork d' un commit avant le référentiel parent. Cette réponse résume les étapes trouvées ici qui déplaceront votre fork vers le même commit que le parent .

1. Modifiez le répertoire dans votre référentiel local.

   • Passez à la branche maître si vous n'êtes pas git checkout master

2. Ajoutez le parent en tant que référentiel distant, git remote add upstream <repo-location>

3. Problème git fetch upstream

4. Problème git rebase upstream/master

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

5. Problème git push origin master

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

Si, comme moi, vous ne soumettez jamais rien directement à 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. Vous ne devez le faire qu'une seule fois:

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

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

git checkout master
git pull upstream master

En supposant que vous n'avez jamais commis quoi que ce soit sur le maître vous-même, vous devriez déjà avoir terminé. Vous pouvez maintenant pousser votre maître local vers votre fork GitHub distant d'origine. Vous pouvez également rebaser votre branche de développement sur votre maître local désormais à jour.

Au-delà de la configuration initiale en amont et de la vérification du maître, il vous suffit d'exécuter la commande suivante pour synchroniser votre maître avec l'amont: git pull upstream master .

Avant-propos: Votre fork est l '"origine" et le référentiel à partir duquel vous avez forké est l' "amont".

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

git clone git@github.com:your_name/project_name.git
cd project_name

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

1. Ajoutez le "amont" à votre référentiel cloné ("origine"):

   git remote add upstream git@github.com:original_author/project_name.git
   

2. Récupérez les commits (et les branches) de "l'amont":

   git fetch upstream
   

3. Basculez vers la branche "master" de votre fork ("origine"):

   git checkout master
   

4. Cachez les changements de votre branche "master":

   git stash
   

5. Fusionnez les changements de la branche "master" de "l'amont" dans votre branche "master" de votre "origine":

   git merge upstream/master
   

6. Résolvez les conflits de fusion, le cas échéant, et validez votre fusion

   git commit -am "Merged from upstream"
   

7. Poussez les changements 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

Depuis novembre 2013, il y a eu une demande de fonctionnalité non officielle ouverte avec GitHub pour leur demander d'ajouter une méthode très simple et intuitive pour garder une branche locale en synchronisation avec l'amont:

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

Remarque: Étant donné que la demande de fonctionnalité n'est pas officielle, il est également conseillé de contacter support@github.compour ajouter votre prise en charge pour une fonctionnalité comme celle-ci à implémenter. La demande de fonctionnalité non officielle ci-dessus pourrait être utilisée comme preuve du montant d'intérêt pour cette mise en œuvre.

À la date de cette réponse, GitHub n'a pas ( ou devrais-je dire plus? ) Cette fonctionnalité dans l'interface Web. Vous pouvez cependant demander support@github.comd'ajouter votre vote pour cela.

En attendant, l'utilisateur de GitHub bardiharborow a créé un outil pour ce faire: https://upriver.github.io/

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

Si vous utilisez GitHub pour Windows ou Mac, ils ont maintenant une fonction en un clic pour mettre à jour les fourches:

1. Sélectionnez le référentiel dans l'interface utilisateur.
2. Cliquez sur le bouton "Mettre à jour depuis l'utilisateur / la branche" en haut.

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

• Open https://github.com/<repo>/commits/<hash>, 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 linux masterle moment de l'écriture.
• Cliquez sur le bouton "Arborescence: ....".
• Tapez le nom de la nouvelle branche et appuyez sur Enter

Vous pouvez ensuite récupérer cette branche dans votre clone local et vous n'aurez pas à renvoyer toutes ces données vers GitHub lorsque vous poussez des modifications au-dessus de cette validation. Ou utilisez l'interface Web pour modifier quelque chose dans cette branche.

Comment cela fonctionne (c'est une supposition, je ne sais pas exactement comment GitHub le fait): les fourches partagent le stockage d'objets et utilisent des espaces de noms pour séparer les références des utilisateurs. Vous pouvez donc accéder à toutes les validations via votre fork, même si elles n'existaient pas au moment de la fourche.

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

Commander à votre succursale

Syntaxe: git branche yourDevelopmentBranch
Exemple: git checkout master

Tirez la branche 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

Je mets à jour mes dépôts fourchus avec cette seule ligne:

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

Utilisez-le si vous ne souhaitez pas ajouter un autre point de terminaison distant à votre projet, comme d'autres solutions publiées ici.

En complément de cette réponse, je cherchais un moyen de mettre à jour toutes les branches distantes de mon référentiel cloné ( origine ) à partir des branches en amont en une seule fois. Voilà comment je l'ai fait.

Cela suppose que vous avez déjà configuré une en amont pointant à distance au référentiel source (où l' origine a été fourchue de) et ont synchronisé avec git fetch upstream.

Exécutez ensuite:

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 référentiel distant en amont et supprime le SHA-1 suivi du refs/heads/préfixe de nom de branche.

Ensuite, pour chacune de ces branches, il pousse la copie locale de la branche de suivi à distance en amont ( refs/remotes/upstream/<branch>côté local) directement vers la branche distante d' origine ( refs/heads/<branch>côté distant).

L'une de ces commandes de synchronisation de branche peut échouer pour l'une des deux raisons: soit la branche en amont a été réécrite, soit vous avez poussé les validations sur cette branche vers votre fork. Dans le premier cas où vous n'avez rien engagé dans la branche de votre fork, il est prudent de pousser avec force (ajoutez le commutateur -f , c'est- git push -fà- dire dans la commande ci-dessus). Dans l'autre cas, cela est normal car votre branche fork a divergé et vous ne pouvez pas vous attendre à ce que la commande sync fonctionne jusqu'à ce que vos validations aient été fusionnées en amont .

L'application "Pull" est une solution de configuration et d'oubli automatique. Il synchronisera la branche par défaut de votre fork avec le référentiel en amont.

Visitez l'URL, cliquez sur le bouton vert "Installer" et sélectionnez les référentiels où vous souhaitez activer la synchronisation automatique.

La branche est mise à jour une fois par heure directement sur GitHub, sur votre machine locale, vous devez tirer la branche principale pour vous assurer que votre copie locale est synchronisée.

Android Studio a maintenant appris à fonctionner avec les référentiels fork de GitHub (vous n'avez même plus besoin d'ajouter de référentiel distant "en amont" par commande de console).

Ouvrir le menu VCS → Git

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

• Rebaser 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 branches du référentiel distant parent ("en amont") seront accessibles dans Android Studio après avoir cliqué sur "Redéfinir ma fourchette GitHub", et vous pourrez facilement les utiliser.

(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 du 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 insérées dans votre référentiel fork.

La commande "fetch" est indispensable pour rester à jour dans un projet: ce n'est que lorsque vous effectuez une "git fetch" que vous serez informé des changements que vos collègues ont poussés sur le serveur distant.

Vous pouvez toujours visiter ici pour d'autres questions

Si vous définissez votre amont. Vérifiez avec git remote -v, cela suffira.

git fetch upstream
git checkout master
git merge --no-edit upstream/master
git push

Cela dépend de la taille de votre référentiel et de la façon dont vous l'avez créé.

S'il s'agit d'un référentiel assez volumineux, vous souhaitiez peut-être le gérer d'une manière spéciale (par exemple, l'historique des suppressions). Fondamentalement, vous pouvez obtenir des différences entre les versions actuelles et en amont, les valider, puis revenir au maître.

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

Je voudrais ajouter à la réponse de @ krlmlr .

Dans un premier temps , le dépôt en forme de fourche a une branche nommée: master. Si vous travaillez sur une nouvelle fonctionnalité ou un correctif, vous devez généralement créer une nouvelle branche featureet apporter les modifications.

Si vous souhaitez que le référentiel forké soit synchronisé avec le référentiel parent, vous pouvez configurer un fichier de configuration ( pull.yml) pour l' application Pull ( dans la branche de fonctionnalité ), comme ceci:

version: "1"
rules:
  - base: feature
    upstream: master
    mergeMethod: merge
  - base: master
    upstream: parent_repo:master
    mergeMethod: hardreset

Cela permet de maintenir à jour la masterbranche du dépôt fourchu avec le dépôt parent. Il maintient la featurebranche du dépôt fourchu mise à jour via la masterbranche du dépôt fourchu en la fusionnant. Cela suppose que la featurebranche est la branche par défaut qui contient le fichier de configuration.

Ici, deux mergemethodssont en jeu, l'un hardresetqui aide à forcer les changements de synchronisation dans la masterbranche du référentiel fourchu avec le référentiel parent et l'autre méthode merge. Cette méthode est utilisée pour fusionner les modifications que vous avez effectuées dans la featurebranche et les modifications effectuées en raison de la synchronisation forcée dans la masterbranche. En cas de conflit de fusion, l'application Pull vous permettra de choisir le prochain plan d'action lors de la demande Pull.

Vous pouvez lire sur les configurations de base et avancées et divers mergemethods ici .

J'utilise actuellement cette configuration dans mon dépôt fourchu ici pour m'assurer qu'une amélioration demandée ici reste à jour.

Il y a deux choses principales à garder un dépôt forké toujours à jour pour de bon.

1. Créez les branches à partir du fork fork et faites-y les modifications .

Ainsi, lorsque votre demande de tirage est acceptée, vous pouvez supprimer la branche en toute sécurité car votre code contribué sera alors en direct dans votre maître de votre dépôt forké lorsque vous le mettrez à jour avec l'amont. Par cela, votre maître sera toujours en bon état pour créer une nouvelle branche pour effectuer un autre changement.

2. Créez un travail planifié pour que le maître de fourche se mette à jour automatiquement .

Cela peut être fait avec cron . Voici un exemple de code si vous le faites sous Linux.

$ crontab -e

mettre ce code sur crontab filepour exécuter le travail sur une base horaire.

0 * * * * sh ~/cron.sh

puis créez le cron.shfichier script et une interaction git avec ssh-agent et / ou attendez comme ci-dessous

#!/bin/sh
WORKDIR=/path/to/your/dir   
REPOSITORY=<name of your repo>
MASTER="git@github.com:<username>/$REPOSITORY.git"   
UPSTREAM=git@github.com:<upstream>/<name of the repo>.git  

cd $WORKDIR && rm -rf $REPOSITORY
eval `ssh-agent` && expect ~/.ssh/agent && ssh-add -l
git clone $MASTER && cd $REPOSITORY && git checkout master
git remote add upstream $UPSTREAM && git fetch --prune upstream
if [ `git rev-list HEAD...upstream/master --count` -eq 0 ]
then
    echo "all the same, do nothing"
else
    echo "update exist, do rebase!"
    git reset --hard upstream/master
    git push origin master --force
fi
cd $WORKDIR && rm -rf $REPOSITORY
eval `ssh-agent -k`

Vérifiez votre référentiel forké. De temps en temps, il affichera toujours cette notification:

Cette branche est même avec <upstream>: master .

Utilisez ces commandes (dans le cas chanceux)

git remote -v
git pull
git fetch upstream
git checkout master
git merge upstream/master --no-ff
git add .
git commit -m"Sync with upstream repository."
git push -v