111 votes

Comment puis-je ' git fetch ' et ' git merge ' d’une branche de suivi à distance (comme ' git pull ')

Je ont mis en place un suivi à distance des branches de git, mais je ne semblent jamais être en mesure de les fusionner dans la branche locale une fois que j'ai mis à jour avec "git fetch'.

Par exemple, supposons que j'ai à distance branche appelée 'une-autre-branche". Je mets ça en place, localement, comme le suivi de la branche à l'aide de

git branch --track an-other-branch origin/an-other-branch

Pour l'instant, donc bon. Mais si cette branche est mise à jour (généralement par moi-même en mouvement de la machine et de la validation de la machine), et je veux le mettre à jour sur la machine d'origine, je suis en cours d'exécution des ennuis avec d'extraction/de fusion:

git fetch origin an-other-branch
git merge origin/an-other-branch

Chaque fois que je fais cela, je reçois un "Déjà à jour le message de la" et rien ne se confond.

Toutefois, un

git pull origin an-other-branch

toujours des mises à jour comme vous l'attendez.

Aussi, l'exécution de la commande git diff

git diff origin/an-other-branch

montre qu'il existe des différences, donc je pense avoir ma syntaxe erronée.

Ce que je fais mal?

EDIT [2010-04-09]: j'ai vérifié une couple de fois, et je ne suis certainement pas sur une autre branche. Mon git fetch' suivi d'un 'git merge" (comme indiqué ci-dessus) faire exactement la même chose qu'un git pull? Je vais obtenir quelques flux de travail présentant les résultats d'un git status etc.

170voto

Gareth Points 42402

Vous ne récupérez une branche, vous récupérez un ensemble à distance :

68voto

cdunn2001 Points 3597

Sélectionner une seule branche: fetch/merge vs pull

Souvent, les gens vous conseillons de séparer les "chercher" à partir de "fusion". Ils disent au lieu de cela:

    git pull remoteR branchB

faire cela:

    git fetch remoteR
    git merge remoteR branchB

Ce qu'ils ne mentionnent pas c'est qu'une telle extraction de commande de récupérer toutes les branches de la télécommande repo, qui n'est pas ce qui tirez la commande. Si vous avez des milliers de branches dans le repo distant, mais vous ne voulez pas les voir tous, vous pouvez exécuter cet obscur commande:

    git fetch remoteR refs/heads/branchB:refs/remotes/remoteR/branchB
    git branch -a  # to verify
    git branch -t branchB remoteR/branchB

Bien sûr, c'est plus difficile à retenir, donc, si vous voulez vraiment éviter l'extraction de toutes les branches, il est préférable de modifier votre .git/config comme décrit dans ProGit.

Hein?

La meilleure explication de tout ce qui est dans le Chapitre 9-5 de ProGit, Git Internes - La Refspec (ou via github). C'est incroyablement difficile à trouver via Google.

Tout d'abord, nous avons besoin de clarifier la terminologie. À distance-direction générale de suivi, il y a généralement 3 branches différentes à savoir:

  1. La direction générale sur le repo distant: refs/heads/branchB à l'intérieur de l'autre repo
  2. Votre télécommande de suivi de branche: refs/remotes/remoteR/branchB dans votre repo
  3. Votre propre branche: refs/heads/branchB à l'intérieur de votre repo

À distance de suivi des branches (en refs/remotes) sont en lecture seule. Vous ne modifiez pas directement. Vous modifiez votre propre branche, puis vous pousser à la correspondante de la direction générale de la télécommande repo. Le résultat n'est pas reflété dans votre refs/remotes jusqu'à ce que après un pull ou chercher. Cette distinction est difficile pour moi de comprendre à partir de l'git man-pages, principalement parce que la branche locale (refs/heads/branchB) est dit "piste" de la télécommande-le suivi de la direction de l' .git/config définit branch.branchB.remote = remoteR.

Penser à 'refs' comme C++ les pointeurs. Physiquement, ils sont des fichiers contenant SHA-digère, mais, fondamentalement, ils sont juste des pointeurs vers la validation de l'arbre. git fetch va ajouter un grand nombre de noeuds de votre commit-arbre, mais comment git décide de ce qui pointeurs à se déplacer est un peu compliqué.

Comme mentionné dans une autre réponse, ni

    git pull remoteR branchB

ni

    git fetch remoteR branchB

serait déplacer refs/remotes/branches/branchB, et ce dernier ne peut certainement pas se déplacer refs/heads/branchB. Cependant, les deux se déplacent FETCH_HEAD. (Vous pouvez en cat aucun de ces fichiers à l'intérieur d' .git/ pour voir quand ils changent.) Et git merge appellerons FETCH_HEAD, tandis que le paramètre MERGE_ORIG, etc.

9voto

VonC Points 414372

Êtes-vous sûr que vous êtes sur le local an-other-branch lors de la fusion?

git fetch origin an-other-branch
git checkout an-other-branch
git merge origin/an-other-branch

L' autre explication:

toutes les modifications de la branche que vous essayiez de fusion ont déjà été fusionné à la direction générale vous êtes actuellement sur.
Plus particulièrement, cela signifie que la branche que vous essayiez de fusion est un parent de votre branche courante

si vous êtes en avance de la télécommande repo par un commit, c'est la distance repo qui est de la date, pas vous.

Mais dans votre cas, si git pull fonctionne, cela signifie simplement que vous n'êtes pas sur la branche de droite.

3voto

RDL Points 3589

Git pull est en fait un outil combo : il fonctionne git fetch (pour les changements) et git merge (fusionnant avec votre copie actuelle)

Etes-vous sûr que vous êtes sur la bonne direction ?

1voto

user1524957 Points 106

Voici les commandes :

Si vous faites cela sur la deuxième ligne :

Il va essayer de fusionner le capitaine local dans votre branche actuelle.

La question, que j’ai compris, est vous avez récupéré déjà localement et souhaitez maintenant fusionner votre succursale à plus tard de la même branche.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X