Question Quelle est la différence entre 'git pull' et 'git fetch'?


Note du modérateur: Étant donné que cette question a déjà eu soixante-quatre réponses affiché, demandez-vous si vous êtes apporter quelque chose de nouveau avant d'en poster un autre.

Quelles sont les différences entre git pull et git fetch?


10125
2017-11-15 09:51


origine


Réponses:


En termes simples, git pull fait un git fetch suivi d'un git merge.

Vous pouvez faire un git fetch à tout moment pour mettre à jour vos branches de suivi à distance sous refs/remotes/<remote>/.

Cette opération ne modifie jamais vos propres succursales locales refs/heads, et est sûr de faire sans changer votre copie de travail. J'ai même entendu parler de gens qui couraient git fetch périodiquement dans un travail cron en arrière-plan (bien que je ne recommanderais pas de le faire).

UNE git pull est ce que vous feriez pour mettre à jour une branche locale avec sa version distante, tout en mettant à jour vos autres branches de suivi à distance.

Documentation Git: git pull


8455
2017-11-15 09:52



  • Lorsque vous utilisez pull, Git essaie de faire automatiquement votre travail pour vous. C'est sensible au contexte, donc Git va fusionner tous les commits tiré dans la branche que vous travaillez actuellement. pull  fusionne automatiquement les validations sans vous laisser les examiner en premier. Si vous ne gérez pas vos succursales, vous risquez de rencontrer des conflits fréquents.

  • Lorsque vous fetch, Git rassemble tous les commits de la branche cible qui n'existent pas dans votre branche actuelle et les stocke dans votre dépôt local. cependant, il ne les fusionne pas avec votre branche actuelle. Ceci est particulièrement utile si vous avez besoin de garder votre référentiel à jour, mais que vous travaillez sur quelque chose qui pourrait casser si vous mettez à jour vos fichiers. Pour intégrer les commits dans votre branche principale, vous utilisez merge.


1849
2017-08-18 08:53



Il est important de comparer la philosophie de conception de git avec la philosophie d'un outil de contrôle de source plus traditionnel comme SVN.

Subversion a été conçu et construit avec un modèle client / serveur. Il existe un seul référentiel qui est le serveur, et plusieurs clients peuvent récupérer du code sur le serveur, travailler dessus, puis le renvoyer au serveur. L'hypothèse est que le client peut toujours contacter le serveur lorsqu'il doit effectuer une opération.

Git a été conçu pour prendre en charge un modèle plus distribué sans avoir besoin d'un référentiel central (bien que vous puissiez certainement en utiliser un si vous le souhaitez). De plus, git a été conçu pour que le client et le «serveur» n'aient pas besoin d'être en ligne en même temps. Git a été conçu pour que les personnes sur un lien non fiable puissent échanger du code par email, même. Il est possible de travailler complètement déconnecté et graver un CD pour échanger du code via git.

Pour prendre en charge ce modèle, git gère un référentiel local avec votre code et un référentiel local supplémentaire qui reflète l'état du référentiel distant. En conservant localement une copie du référentiel distant, git peut déterminer les modifications nécessaires même lorsque le référentiel distant n'est pas accessible. Plus tard, lorsque vous devez envoyer les modifications à quelqu'un d'autre, git peut les transférer sous la forme d'un ensemble de modifications à partir d'un moment connu dans le référentiel distant.

  • git fetchest la commande qui dit "mettre à jour ma copie locale du dépôt distant".

  • git pull dit "apporter les changements dans le dépôt distant où je garde mon propre code."

Normalement git pull est-ce en faisant un git fetch pour mettre à jour la copie locale du référentiel distant, puis fusionner les modifications dans votre propre référentiel de code et éventuellement votre copie de travail.

L'emporter est de garder à l'esprit qu'il y a souvent au moins trois copies d'un projet sur votre poste de travail. Une copie est votre propre référentiel avec votre propre historique de validation. La deuxième copie est votre copie de travail où vous éditez et construisez. La troisième copie est votre copie locale "mise en cache" d'un référentiel distant.


1007
2018-03-31 18:43



Voici L'image d'Oliver Steele de comment tout cela s'accorde:

enter image description here

Si l'intérêt est suffisant, je suppose que je pourrais mettre à jour l'image pour ajouter git clone et git merge...


660
2018-06-09 13:30



Un cas d'utilisation de git fetch est ce qui suit vous dira tous les changements dans la branche distante depuis votre dernière traction ... ainsi vous pouvez vérifier avant de faire une traction réelle, qui pourrait changer des dossiers dans votre branche courante et copie de travail.

git fetch
git diff ...origin

427
2018-05-07 19:23



Cela m'a coûté un petit peu de comprendre quelle était la différence, mais c'est une explication simple. master dans votre localhost est une branche.

Lorsque vous clonez un référentiel, vous récupérez le référentiel entier sur votre hôte local. Cela signifie qu'à ce moment-là vous avez un pointeur d'origine / maître vers HEAD et le maître pointant vers le même HEAD.

lorsque vous commencez à travailler et que vous vous engagez, avancez le pointeur principal vers HEAD + vos commits. Mais le pointeur d'origine / maître indique toujours ce que c'était lorsque vous avez cloné.

Donc la différence sera:

  • Si vous faites un git fetch il va juste chercher tous les changements dans le dépôt distant (GitHub) et déplacez le pointeur d'origine / maître sur HEAD. Pendant ce temps, votre maître de succursale local continuera de pointer vers où il a.
  • Si vous faites un git pull, il fera essentiellement aller chercher (comme expliqué précédemment) et fusionner toutes les nouvelles modifications à votre branche principale et déplacer le pointeur vers HEAD.

341
2018-05-11 18:37



Parfois, une représentation visuelle aide.

enter image description here


179
2018-01-25 17:28



Brièvement

git fetch est similaire à pull mais ne fusionne pas. c'est-à-dire qu'il récupère les mises à jour à distance (refs et objects) mais votre local reste le même (c.-à-d. origin/master est mis à jour mais master reste le même) .

git pull tire vers le bas à partir d'une télécommande et fusionne instantanément.

Plus

git clone clone un repo.

git rebase enregistre des éléments de votre branche actuelle qui ne se trouve pas dans la branche amont vers une zone temporaire. Votre succursale est maintenant la même qu'avant le début de vos modifications. Alors, git pull -rebase Déplacez les modifications à distance, rembobinez votre branche locale, relisez vos modifications par-dessus le sommet de votre branche actuelle, jusqu'à ce que vous soyez à jour.

Aussi, git branch -a vous montrera exactement ce qui se passe avec toutes vos branches - locales et distantes.

Cet article de blog était utile:

La différence entre git pull, git fetch et git clone (et git rebase) - Mike Pearce

et couvre git pull, git fetch, git clone et git rebase.

====

METTRE À JOUR

Je pensais que je mettrais à jour ceci pour montrer comment vous l'utiliseriez dans la pratique.

  1. Mettez à jour votre rapport local à partir de la télécommande (mais ne fusionnez pas):

    git fetch

  2. Après avoir téléchargé les mises à jour, voyons les différences:

    git diff maître origine / maître

  3. Si vous êtes satisfait de ces mises à jour, fusionnez:

    git pull

Remarques:

À l'étape 2: Pour en savoir plus sur les différences entre les locales et les télécommandes, voir: comparer la branche git locale avec la branche distante?

Sur l'étape 3: Il est probablement plus précis (par exemple sur un repo à changement rapide) de faire un git rebase origin ici. Voir @Justin Ohms commentaire dans une autre réponse.

Voir également: http://longair.net/blog/2009/04/16/git-fetch-and-merge/ 


165
2018-04-13 17:31



git-pull - Récupère et fusionne avec un autre référentiel ou une branche locale
SYNOPSIS

git tire ...
LA DESCRIPTION

Exécute git-fetch avec les paramètres donnés et appelle git-merge pour fusionner
récupéré tête (s) dans la branche actuelle. Avec --rebase, appelle git-rebase
au lieu de git-merge.

Notez que vous pouvez utiliser. (répertoire courant) en tant que <repository> pour tirer
à partir du référentiel local - ceci est utile lors de la fusion de branches locales
dans la branche actuelle.

Notez également que les options destinées à git-pull lui-même et git-merge sous-jacent
doit être donné avant les options destinées à git-fetch.

Vous obtiendriez si vous voulez que les histoires soient fusionnées, vous obtiendriez si vous voulez juste le codez comme quelqu'un a étiqueté des articles ici.


155
2017-11-15 09:52



Vous pouvez extraire à partir d'un référentiel distant, voir les différences, puis tirer ou fusionner.

Ceci est un exemple pour un dépôt distant appelé origin et une branche appelée master suivi de la branche distante origin/master:

git checkout master                                                  
git fetch                                        
git diff origin/master
git rebase origin master

143
2018-03-21 11:07



La réponse courte et facile est que git pull est simplement git fetch suivi par git merge.

Il est très important de noter que git pull volonté Fusionner automatiquement si vous le souhaitez ou non. Cela pourrait, bien sûr, entraîner des conflits de fusion. Disons que votre télécommande est origin et votre branche est master. Si vous git diff origin/master Avant de tirer, vous devriez avoir une idée des conflits de fusion potentiels et préparer votre succursale locale en conséquence.

En plus de tirer et de pousser, quelques workflows impliquer git rebase, comme celui-ci, que je paraphrase de l'article lié:

git pull origin master
git checkout foo-branch
git rebase master
git push origin foo-branch

Si vous vous trouvez dans une telle situation, vous pourriez être tenté de git pull --rebase. À moins que vous sachiez vraiment, vraiment ce que vous faites, je vous déconseillerais cela. Cet avertissement provient du man page pour git-pull, version 2.3.5:

Ceci est un mode de fonctionnement potentiellement dangereux. Il réécrit   l'histoire, ce qui ne présage rien de bon lorsque vous avez publié cette histoire   déjà. N'utilisez pas cette option à moins d'avoir lu git-rebase (1)   soigneusement.


132
2018-05-15 20:53