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


11920

Quelles sont les différences entre git pullet git fetch?


364
J'ai trouvé cet article bien écrit sur git fetch et git pull qui vaut la peine d'être lu: longair.net/blog/2009/04/16/git-fetch-and-merge
Marcos Oliveira

51
Notre approche alternative est devenue git fetch; git reset --hard origin/masterpartie intégrante de notre flux de travail. Il supprime les modifications locales, vous permet de rester à jour avec le maître MAIS vous assure de ne pas simplement ajouter de nouvelles modifications en plus des modifications actuelles et de faire un gâchis. Nous l'avons utilisé pendant un certain temps et il se sent beaucoup plus sûr dans la pratique. Assurez-vous simplement d'ajouter / valider / ranger tout travail en cours en premier!
Michael Durrant

26
Assurez-vous de savoir comment utiliser correctement git stash. Si vous demandez «tirer» et «chercher», alors peut-être que «planquer» devra également être expliqué ...
Henry Heleine

36
Beaucoup de gens venant de Mercurial continuent à utiliser "git pull", pensant que c'est un équivalent de "hg pull". Ce n'est pas le cas. L'équivalent de Git de «hg pull» est «git fetch».
Serge Shultz

8
La commande git fetch récupère le code mis à jour avec la branche et obtiendra également les nouvelles branches ajoutées dans votre commande locale, git pull ne récupère que le code mis à jour de la branche actuelle
Kartik Patel

Réponses:


9920

En termes simples, git pullfait un git fetchsuivi 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 aucune de vos propres succursales locales refs/headset peut être effectuée sans changer votre copie de travail. J'ai même entendu parler de gens qui couraient git fetchpériodiquement dans un travail cron en arrière-plan (bien que je ne recommanderais pas de le faire).

A git pullest ce que vous feriez pour mettre à jour une succursale locale avec sa version distante, tout en mettant à jour vos autres succursales de suivi à distance.

Documentation Git - Git Pull :

Dans son mode par défaut, git pullest un raccourci pour git fetchsuivi de git merge FETCH_HEAD.


326
"Un" git pull "est ce que vous feriez pour mettre à jour votre référentiel" <- la mise à jour du référentiel n'est-elle pas déjà effectuée par fetch? ne voulez-vous pas dire qu'il met à jour vos succursales locales avec les succursales distantes? Pour la fusion: il fusionne les branches distantes avec vos copies locales de ces branches, ou qu'est-ce qu'il fusionne exactement ici?
Albert

194
@Albert: Oui, c'est bizarrement formulé. git pullfusionnera toujours dans la branche actuelle . Vous sélectionnez donc la branche à partir de laquelle vous souhaitez tirer , et il la tire dans la branche actuelle. La branche from peut être locale ou distante; il peut même s'agir d'une branche distante qui n'est pas enregistrée git remote(ce qui signifie que vous passez une URL sur la git pullligne de commande).
intuition

129
@espertus: Non. Pousser ne fait jamais automatiquement une fusion. L'utilisateur est censé tirer, résoudre tous les conflits de fusion localement, puis repousser vers la télécommande.
Greg Hewgill

33
Si j'en suis /home/alice/et que je fais git fetch /home/bob, quels paramètres dois-je passer aux suivants git merge?
ripper234

106
Remarque pour les personnes apprenant Git: pullne peut pas réellement être émulé par un fetchplus un merge. Je viens de récupérer un changement où seul un pointeur de branche distant change et mergerefuse de faire quoi que ce soit. pull, d'autre part, avance rapidement ma branche de suivi.
Roman Starkov

2173
  • Lorsque vous utilisez pull, Git essaie de faire automatiquement votre travail pour vous. Il est sensible au contexte , donc Git fusionnera toutes les validations extraites dans la branche dans laquelle vous travaillez actuellement. pull Fusionne automatiquement les validations sans vous permettre de les consulter au préalable . Si vous ne gérez pas étroitement vos succursales, vous pouvez rencontrer des conflits fréquents.

  • Lorsque vous fetch, Git rassemble toutes les validations de la branche cible qui n'existent pas dans votre branche actuelle et les stocke dans votre référentiel local . Cependant, il ne les fusionne pas avec votre branche actuelle . Cela est particulièrement utile si vous devez maintenir votre référentiel à jour, mais que vous travaillez sur quelque chose qui pourrait se casser si vous mettez à jour vos fichiers. Pour intégrer les validations dans votre branche principale, vous utilisez merge.


34
D'accord, super commentaire. C'est pourquoi je déteste le git pull. Quand serait-il judicieux de laisser un outil de révision effectuer des modifications de code pour vous? Et n'est-ce pas ce que fait la fusion de deux fichiers? Et si ces deux modifications sont physiquement séparées dans le fichier, mais LOGIQUEMENT en désaccord?
Lee Dixon

126
@elexhobby short put, git fetchne met à jour que votre .git/répertoire (AKA: dépôt local) et rien à l'extérieur .git/(AKA: arbre de travail). Cela ne change pas vos succursales locales et ne touche pas non masterplus. Il touche remotes/origin/mastercependant (voir git branch -avv). Si vous avez plus de télécommandes, essayez git remote update. Il s'agit d'une git fetchtélécommande pour toutes les télécommandes en une seule commande.
Tino

24
@Tino le vôtre est vraiment le point le plus important. Les gens ne savent peut-être pas que les branches "distantes" sont en fait stockées sous forme de hachage .git/refs/remotes/origin/.
Chris

13
Lorsque vous récupérez, Git rassemble toutes les validations de la branche cible qui n'existent pas dans votre branche actuelle et les stocke dans votre référentiel local - comment puis-je voir ce qui a été apporté de la télécommande et comment le fusionner dans mes branches locales?
ア レ ッ ク ス

13
@Tino Ce que je ne comprends toujours pas, c'est ... à quoi ça sert? Pourquoi utiliser la récupération si elle ne se met à jour .git? Quel est l'avantage prévu et que dois-je faire après cela?
BadHorsie

1210

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 y a un seul référentiel qui est le serveur, et plusieurs clients peuvent récupérer le code du serveur, y travailler, puis le remettre sur le serveur. L'hypothèse est que le client peut toujours contacter le serveur lorsqu'il a besoin d'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). Git a également é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 même échanger du code par e-mail. Il est possible de travailler complètement déconnecté et de graver un CD pour échanger du code via git.

Afin de prendre en charge ce modèle, git maintient un référentiel local avec votre code et également un référentiel local supplémentaire qui reflète l'état du référentiel distant. En conservant une copie du référentiel distant localement, 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 en tant qu'ensemble de modifications à partir d'un moment connu du référentiel distant.

  • git fetch est la commande qui dit "mettre à jour ma copie locale du référentiel distant".

  • git pull dit "apporter les modifications dans le référentiel distant à l'endroit où je conserve mon propre code."

git pullCela se fait normalement en effectuant une mise git fetchà jour de la copie locale du référentiel distant, puis en fusionnant les modifications dans votre propre référentiel de code et éventuellement votre copie de travail.

Le point à retenir 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 commit. La deuxième copie est votre copie de travail où vous éditez et construisez. La troisième copie est votre copie locale "en cache" d'un référentiel distant.


75
Techniquement, les référentiels locaux et distants sont vraiment les mêmes. Dans Git, un référentiel est un DAG de commits pointant vers leurs parents. Les branches ne sont, techniquement, rien de plus que des noms significatifs de commits. La seule différence entre les succursales locales et distantes est que celles distantes sont préfixées avec remoteName/ Git à partir du sol est une très bonne lecture. Une fois que vous comprenez comment Git fonctionne - et c'est magnifiquement simple , vraiment - tout a du sens.
Emil Lundberg

13
Merci beaucoup pour l'explication. Je ne comprenais pas vraiment jusqu'à présent que Git a été conçu, vous n'avez donc pas besoin d'avoir un référentiel central. Tout le monde dit toujours "DVCS" lors de la description de Git, mais en tant que programmeur relativement nouveau, cela ne signifie rien pour moi. Je n'ai jamais vu de CVCS, et je n'ai jamais travaillé avec un référentiel distant central quand je collabore avec d'autres (c'est-à-dire Github), donc jusqu'à présent, je n'ai pas encore compris ce qui rend Git spécial.
Brian Peterson

7
Donc, sur cette base, pourquoi n'est-ce pas une bonne idée de git-fetch avec un travail cron? Garder toujours une copie de la télécommande avec laquelle vous travaillez sur votre machine locale semble être une bonne idée. En fait, j'ai envie d'écrire un script qui vérifie si j'ai mis à jour ma télécommande au cours des dernières 24 heures et de la connecter avec un crochet udev pour une connexion Internet.
Brian Peterson

24
L'une des raisons pour lesquelles ce n'est PAS une bonne idée d'avoir un travail cron: souvent lorsque je travaille sur un nouveau ticket ou sur des mises à jour d'une branche, j'aime voir les changements être récupérés. Si les changements ne surviennent pas pendant une extraction, je serai plus confiant en demandant à mon collègue programmeur "hey as-tu poussé?". J'ai également une idée de la quantité de «taux de désabonnement» dans le référentiel depuis ma dernière extraction. Cela permet également de me donner une idée de la quantité et de la rapidité des modifications actuellement apportées à ce référentiel.
Michael Durrant

5
@Nabheet La chose est que Git est orienté contenu. Il stocke les données une seule fois et les pointe plusieurs fois. C'est pourquoi dans Git, même plusieurs validations au-dessus d'un original n'affectent pas beaucoup la taille du dépôt, car la plupart des objets sont les mêmes.
cst1992

890

Voici l'image d'Oliver Steele de la façon dont tout cela s'imbrique :

entrez la description de l'image ici

S'il y a suffisamment d'intérêt, je suppose que je pourrais mettre à jour l'image à ajouter git cloneet git merge...


156
Une image mise à jour avec git cloneet git mergeserait très utile!
MEMark

20
Oui, veuillez ajouter git merge- cela devrait clairement montrer que mergeappelé séparément n'est PAS la même chose que d'appeler pullcar il pullfusionne uniquement à distance et ignore vos validations locales dans votre branche locale qui suit la branche distante à partir de laquelle vous êtes extrait.
JustAMartin

12
Une image vaut mieux que mille mots! L'image mise à jour avec le clone et le flux de données de fusion est-elle prête quelque part? Tout autre flux de données en plus de ce qui est déjà dans le diagramme?
shikhanshu

10
@Contango veuillez ajouter un clone et fusionner. Serait utile pour les débutants comme moi.
loue le

11
Il y a deux diagrammes montrant le clonage et la fusion dans d'autres réponses (ci-dessous) par th3sly et thedarkpassenger.
intotecho

488

Un cas d'utilisation git fetchest que ce qui suit vous indiquera toutes les modifications apportées à la branche distante depuis votre dernier pull ... afin que vous puissiez vérifier avant de faire un pull réel, ce qui pourrait changer les fichiers dans votre branche actuelle et votre copie de travail.

git fetch
git diff ...origin

Voir: https://git-scm.com/docs/git-diff concernant la syntaxe à double et triple points dans la commande diff


9
pourquoi pas git diff ..origin?
Erik Kaplun

3
git diff origin et git diff ..origin semblent fonctionner mais pas ce truc bizarre ...
Marc

19
@Compustretch Il ne devait pas y avoir d'espace. git diff ...originest équivalent à git diff $(git-merge-base HEAD origin) origin(voir la git diff [--options] <commit>...<commit> [--] [<path>…]section de kernel.org/pub/software/scm/git/docs/git-diff.html#_description ), qui est différent de git diff origin; git diff ...originest conceptuellement les modifications apportées origindepuis la branche courante depuis la branche origin, tout en git diff originincluant également l'inverse des modifications apportées dans la branche actuelle depuis la branche origin.
Max Nanasy

2
aucune des .. commandes n'a fonctionné pour moi (sous Windows), mais git diff origin/masterfonctionne, comme mentionné ci-dessous
Brian Burns

même ici en utilisant git 2.0.0 sur OSX. Aucune de ces commandes n'a fonctionné. Ont-ils été dépréciés?
K.-Michael Aye

373

Cela m'a coûté un peu pour comprendre quelle était la différence, mais c'est une explication simple. masterdans votre localhost est une succursale.

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

lorsque vous commencez à travailler et effectuez des validations, vous faites avancer le pointeur principal vers HEAD+ vos validations. Mais le pointeur d'origine / maître pointe toujours vers ce qu'il était lorsque vous avez cloné.

La différence sera donc:

  • Si vous faites git fetchcela, il récupérera simplement toutes les modifications dans le référentiel distant ( GitHub ) et déplacera le pointeur d'origine / maître vers HEAD. Pendant ce temps, votre directeur de succursale local indiquera toujours où il se trouve.
  • Si vous faites un git pull, il va essentiellement récupérer (comme expliqué précédemment) et fusionner toutes les nouvelles modifications apportées à votre branche principale et déplacer le pointeur vers HEAD.

14
origin / master est une branche locale qui est une COPIE de master sur l'origine. Lorsque vous récupérez, vous mettez à jour local: / origin / master. Une fois que vous comprenez vraiment que tout dans git est une branche, cela a beaucoup de sens et est un moyen très puissant de maintenir différents changements, de créer rapidement des branches locales, de fusionner et de rebaser, et de tirer généralement beaucoup de valeur de la branche bon marché modèle.
cam8001

3
Toujours déroutant. Je pensais que git fetchc'était littéralement de télécharger les modifications sur le référentiel distant dans votre référentiel local, mais PAS de les valider - c'est-à-dire, elles doivent encore être ajoutées / validées dans votre référentiel local.
krb686

3
fetch ne tire que de remote / origin (github) vers votre origine locale. Mais il ne le fusionne pas avec vos fichiers de travail réels. si vous faites un pull, il sera récupéré et fusionné dans vos fichiers de travail actuels
Gerardo

223

Parfois, une représentation visuelle aide.

entrez la description de l'image ici


18
Je pense que l'image doit montrer qu'elle affecte également le dépôt local. C'est-à-dire que Git pull est une combinaison affectant le dépôt local et la copie de travail. À l'heure actuelle, il semble que cela affecte uniquement la copie de travail.
non

10
@太極者無極而生Convenu - cette image est assez trompeur, car il fait ressembler git pullest sautent le Fetch, ce qui bien sûr est inexacte.
forresthopkinsa

9
Quelle est la différence entre un «référentiel local» et une «copie de travail»? Ne sont-ils pas tous les deux locaux sur l'ordinateur?
theITvideos

1
À quoi sert git fetch alors? comment voir quelle différence y a-t-il dans le référentiel local et la copie de travail?
Vikash

2
@theITvideos Non, ce n'est pas le cas. Un référentiel local est l'endroit où va votre code (du référentiel de travail) lorsque vous vous engagez. (Il va au repo à distance lorsque vous poussez).
Vikash

219

Brièvement

git fetchest similaire pullmais ne fusionne pas. c'est-à-dire qu'il récupère les mises à jour à distance ( refset objects) mais votre local reste le même (c'est-à-dire qu'il origin/masterest mis à jour mais masterreste le même).

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

Plus

git clone clone un dépôt.

git rebaseenregistre les éléments de votre branche actuelle qui ne se trouvent pas dans la branche en amont dans une zone temporaire. Votre branche est maintenant la même qu'avant le début de vos modifications. Ainsi, vous git pull -rebaseabaissez les modifications à distance, rembobinez votre branche locale, relisez vos modifications par-dessus votre branche actuelle jusqu'à ce que vous soyez à jour.

En outre, git branch -avous montrera exactement ce qui se passe avec toutes vos succursales - locales et distantes.

Ce billet de blog était utile:

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

et couvertures git pull, git fetch, git cloneet git rebase.

====

MISE À JOUR

Je pensais que je mettrais à jour ceci pour montrer comment vous utiliseriez réellement ceci dans la pratique.

  1. Mettez à jour votre référentiel local à distance (mais ne fusionnez pas):

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

    git diff master origin/master 
    
  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 télécommandes locales et distantes, voir: Comment comparer une branche git locale avec sa branche distante?

À l'étape 3: il est probablement plus précis (par exemple sur un référentiel à évolution rapide) de faire un git rebase originici. Voir le commentaire @Justin Ohms dans une autre réponse.

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


1
Cela me semble que si quelqu'un veut simplement que le code local reflète "la pointe", il devrait l'utiliser git clone. Je mets l'astuce entre guillemets, car je suppose que cela signifierait quel que soit le maître et ce que quelqu'un "téléchargerait comme zip" sur github.com
Chris K

3
Et si vous n'êtes pas satisfait des changements après avoir récupéré? que faire ensuite?
Kugutsumen

Votre paragraphe sur le rebase était exactement ce que je cherchais. L'idée de mettre à zéro tout, de mettre à jour à distance, puis de rejouer vos modifications par-dessus les validations précédentes qui se sont produites pendant que vous travailliez. Explication parfaite en supposant que c'est correct. ;)
coblr

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

git pull…
LA DESCRIPTION

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

Notez que vous pouvez utiliser. (répertoire courant) comme <référentiel> à 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 tireriez si vous voulez que les histoires soient fusionnées, vous iriez chercher si vous vouliez juste le codez, car une personne a tagué certains articles ici.


5
Très intéressant, mais je ne vois pas vraiment de cas d'utilisation où vous voulez "juste le code". Et qu'arrive-t-il avec votre code lorsque vous récupérez? Est-il effacé? Que se passe-t-il lorsque la télécommande change? Comment cela se passe-t-il dans votre référentiel sans effacer votre code si vous ne fusionnez pas?
e-satis

11
@ e-satis: La branche distante est également stockée localement sur votre machine. Ainsi, lorsque vous le faites, git fetchil récupère les modifications du référentiel et met à jour votre branche distante locale. Cela n'affecte pas votre branche locale qui suit la branche distante locale, donc n'affecte pas votre copie de travail. Maintenant, lorsque vous effectuez une opération, mergeil fusionnera les modifications extraites avec votre branche locale.
jeffreyveon

Un cas d'utilisation simple pour la commande fetch: effectuez des opérations fastidieuses impliquant des validations récentes d'autres personnes, telles qu'une fusion ou une révision de code, en accédant uniquement à votre référentiel local à jour sans exigences de connectivité réseau, car vous avez précédemment utilisé fetch pour télécharger tout ce dont vous avez besoin rapidement (par exemple lorsque vous visitez un autre développeur et connecté à un autre réseau de référentiel). La commande pull téléchargerait les mêmes validations, mais la fusion qu'elle effectue peut être indésirable.
Lorenzo Gatti

163

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

Voici un exemple pour un référentiel distant appelé originet une branche appelée mastersuivi de la branche distante origin/master:

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

35
Vous voudrez probablement ignorer l'extraction et faire juste une "origine de rebase git" comme dernière étape puisque vous avez déjà récupéré les modifications. La raison en est que quelqu'un aurait pu pousser des changements dans le temps depuis que vous avez fait la récupération et ceux-ci n'auraient pas été en charge que vous avez fait la revue de diff.
Justin Ohms

158

La réponse courte et facile git pullest simplement git fetchsuivie git merge.

Il est très important de noter que git pullcela fusionnera automatiquement, que cela vous plaise ou non . Cela pourrait, bien sûr, entraîner des conflits de fusion. Disons que votre télécommande est originet votre succursale l'est master. Si vous git diff origin/masteravant 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, certains workflows impliquent 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 le faire git pull --rebase. À moins que vous ne sachiez vraiment, vraiment ce que vous faites, je vous déconseille. Cet avertissement provient de la manpage de git-pull, version 2.3.5:

Il s'agit d'un mode de fonctionnement potentiellement dangereux. Il réécrit l'histoire, ce qui n'est pas de bon augure lorsque vous avez déjà publié cette histoire. N'utilisez cette option que si vous avez lu attentivement git-rebase (1).


2
@JustinOhms Si ce git pull --rebasen'est pas la bonne chose dans la situation donnée, est-ce bien si cela se fait en deux étapes? Si c'est la bonne chose à faire, quel est l'avantage supplémentaire de le faire en deux étapes?
Kaz

@Kaz - car le rebase n'est pas automatique. La récupération des modifications vous permet d'abord de faire le jugement. Cela ne résout pas le problème de rebasage de l'historique que vous avez déjà poussé. Il vous permettra de voir s'il est sûr de rebaser des modifications que vous n'avez pas encore poussées.
Justin Ohms

2
@JustinOhms Comment décideriez-vous s'il est sûr de rebaser les modifications? Je voudrais juste essayer git rebase, et revenir en arrière si cela faisait un gâchis, auquel cas je ferais aussi bien git pull --rebase. Mais peut-être avez-vous un autre moyen?
Kaz

3
@KaZ gitk vous permet de voir visuellement la structure de la branche. Il vous montrera la position de votre chef local, de vos télécommandes et de vos structures de branche par rapport à ce que vous avez récupéré. De cette façon, vous pouvez vous assurer que vous ne réinitialisez pas les modifications extraites basées sur un ancêtre antérieur à ce que vous avez déjà transmis à vos télécommandes.
Justin Ohms

À utiliser rebaselorsque vous travaillez sur une branche locale qui n'est pas déjà poussée. Si vous travaillez sur une branche qui existe dans la télécommande, cela rebasepeut entraîner des problèmes désagréables, vous devriez donc préférer un habitué merge.
Justus Romijn

151

OK , voici quelques informations sur git pullet git fetch, afin que vous puissiez comprendre les différences réelles ... en quelques mots simples, fetch obtient les dernières données, mais pas les modifications de code et ne va pas jouer avec votre code de branche local actuel, mais tirez get le code change et fusionnez-le dans votre branche locale, lisez la suite pour obtenir plus de détails sur chacun d'eux:

git fetch

Il téléchargera toutes les références et les objets et toutes les nouvelles branches dans votre référentiel local ...

Récupérer les branches et / ou les balises (collectivement, "refs") d'un ou plusieurs autres référentiels, ainsi que les objets nécessaires pour compléter leurs historiques. Les branches de suivi à distance sont mises à jour (voir la description ci-dessous pour savoir comment contrôler ce comportement).

Par défaut, toute balise qui pointe vers les historiques en cours de récupération est également récupérée; l'effet est de récupérer les balises qui pointent vers les branches qui vous intéressent. Ce comportement par défaut peut être modifié en utilisant les options --tags ou --no-tags ou en configurant remote..tagOpt. En utilisant une refspec qui récupère les balises de manière explicite, vous pouvez également récupérer des balises qui ne pointent pas dans les branches qui vous intéressent.

git fetch peut récupérer à partir d'un seul référentiel nommé ou d'une URL, ou à partir de plusieurs référentiels à la fois si est donné et qu'il existe des télécommandes. entrée dans le fichier de configuration. (Voir git-config 1 ).

Lorsqu'aucune télécommande n'est spécifiée, par défaut, la télécommande d'origine sera utilisée, sauf si une branche en amont est configurée pour la branche actuelle.

Les noms des références récupérées, ainsi que les noms des objets vers lesquels ils pointent, sont écrits dans .git / FETCH_HEAD. Ces informations peuvent être utilisées par des scripts ou d'autres commandes git, telles que git-pull.


git pull

Il appliquera les modifications de distance à la branche actuelle en local ...

Incorpore les modifications d'un référentiel distant dans la branche actuelle. Dans son mode par défaut, git pull est un raccourci pour git fetch suivi de git merge FETCH_HEAD.

Plus précisément, git pull exécute git fetch avec les paramètres donnés et appelle git merge pour fusionner les têtes de branche récupérées dans la branche courante. Avec --rebase, il exécute git rebase au lieu de git merge.

devrait être le nom d'un référentiel distant transmis à git-fetch 1 . peut nommer une référence arbitraire à distance (par exemple, le nom d'une balise) ou même une collection de références avec des branches de suivi à distance correspondantes (par exemple, refs / heads / : refs / remotes / origin / ), mais généralement c'est le nom d'une branche dans le référentiel distant.

Les valeurs par défaut pour et sont lues à partir de la configuration «distante» et «fusionnée» pour la branche actuelle telle que définie par git-branch --track.


Je crée également le visuel ci-dessous pour vous montrer comment git fetchet git pulltravailler ensemble ...

git pull et git fetch


10
Si vous aimez l'image, jetez un oeil à la feuille de triche git, qui est le même genre de choses pour toutes les commandes git ... ndpsoftware.com/git-cheatsheet.html
Tom

3
Le clone n'affecte-t-il pas également le référentiel local (copie de tout l'historique à distance)?
Tom Loredo

135

entrez la description de l'image ici

Cette représentation graphique interactive est très utile pour comprendre git: http://ndpsoftware.com/git-cheatsheet.html

git fetchil suffit de «télécharger» les modifications de la télécommande vers votre référentiel local. git pulltélécharge les modifications et les fusionne dans votre branche actuelle. "Dans son mode par défaut, git pullest un raccourci pour git fetchsuivi de git merge FETCH_HEAD."


18
Personnes, cliquez sur le lien pour interagir avec les différentes colonnes. Cette feuille de sécurité est la meilleure ressource que j'ai vue pour bien comprendre les différences entre chaque commande.
M. Luisa Carrión

Cette réponse doit aller en haut
Tessaracter

126

Prime:

En parlant de pull & fetch dans les réponses ci-dessus, je voudrais partager une astuce intéressante,

git pull --rebase

Cette commande ci-dessus est la commande la plus utile de ma vie git qui a permis de gagner beaucoup de temps.

Avant de pousser vos nouvelles validations sur le serveur, essayez cette commande et elle synchronisera automatiquement les dernières modifications du serveur (avec une extraction + fusion) et placera votre validation en haut dans git log. Pas besoin de s'inquiéter de l'extraction / fusion manuelle.

Plus de détails sur: http://gitolite.com/git-pull--rebase


4
Bon conseil, même s'il convient de mentionner aux nouveaux utilisateurs de git que le rebase modifie les hachages de validation (j'ai trouvé cela surprenant venant de subversion).
AlexMA

1
Pouvez-vous expliquer quelle est la différence entre git pullet git pull --rebase?
shaijut

2
Voir l'avertissement brutal sur cette méthode dans une réponse ci-dessus: stackoverflow.com/a/6011169/241244

118

J'aime avoir une représentation visuelle de la situation pour saisir ces choses. Peut-être que d'autres développeurs aimeraient le voir aussi, alors voici mon ajout. Je ne suis pas totalement sûr que tout soit correct, veuillez donc commenter si vous trouvez des erreurs.

                                         LOCAL SYSTEM
                  . =====================================================    
================= . =================  ===================  =============
REMOTE REPOSITORY . REMOTE REPOSITORY  LOCAL REPOSITORY     WORKING COPY
(ORIGIN)          . (CACHED)           
for example,      . mirror of the      
a github repo.    . remote repo
Can also be       .
multiple repo's   .
                  .
                  .
FETCH  *------------------>*
Your local cache of the remote is updated with the origin (or multiple
external sources, that is git's distributed nature)
                  .
PULL   *-------------------------------------------------------->*
changes are merged directly into your local copy. when conflicts occur, 
you are asked for decisions.
                  .
COMMIT            .                             *<---------------*
When coming from, for example, subversion, you might think that a commit
will update the origin. In git, a commit is only done to your local repo.
                  .
PUSH   *<---------------------------------------*
Synchronizes your changes back into the origin.

Certains avantages majeurs pour avoir un miroir récupéré de la télécommande sont:

  • Performances (faites défiler tous les validations et tous les messages sans essayer de les presser sur le réseau)
  • Commentaires sur l'état de votre référentiel local (par exemple, j'utilise SourceTree d'Atlassian, qui me donnera une ampoule indiquant si je suis en avance ou en retard par rapport à l'origine. Ces informations peuvent être mises à jour avec un GIT FETCH).

N'est-ce pas git pullégalement effectuer une fusion, c'est-à-dire aller jusqu'à la copie de travail?
Kamiel Wanrooij

Bon point, oui, il mettra toutes les modifications dans votre copie de travail, puis vous pourrez le valider vous-même dans le dépôt local. Je mettrai à jour le visuel.
Justus Romijn

@JustusRomijn Un pull ne met-il pas également à jour le référentiel local? Ne devrait-il pas y avoir un astérisque entre l'origine et les astérisques de copie de travail?
user764754

2
@ user764754 Lorsque vous tirez, votre copie de travail obtient les modifications (il peut également y avoir des conflits que vous devrez peut-être résoudre). Vous devez toujours le valider dans votre référentiel local.
Justus Romijn

@JustusRomijn: Merci pour l'illustration. Ce serait bien si vous pouviez rendre le diagramme plus complet en illustrant les effets d'opérations telles que la réinitialisation, la sélection des états du référentiel.
jith912

106

J'ai également eu du mal avec cela. En fait, je suis arrivé ici avec une recherche Google sur exactement la même question. En lisant toutes ces réponses, j'ai finalement peint une image dans ma tête et j'ai décidé d'essayer de le faire en regardant l'état des 2 référentiels et 1 bac à sable et les actions effectuées au fil du temps tout en regardant la version d'entre eux. Voici donc ce que j'ai trouvé. Veuillez me corriger si j'ai foiré quelque part.

Les trois repos avec un fetch:

---------------------     -----------------------     -----------------------
- Remote Repo       -     - Remote Repo         -     - Remote Repo         -
-                   -     - gets pushed         -     -                     -
- @ R01             -     - @ R02               -     - @ R02               -
---------------------     -----------------------     -----------------------

---------------------     -----------------------     -----------------------
- Local Repo        -     - Local Repo          -     - Local Repo          -
- pull              -     -                     -     - fetch               -
- @ R01             -     - @ R01               -     - @ R02               -
---------------------     -----------------------     -----------------------

---------------------     -----------------------     -----------------------
- Local Sandbox     -     - Local Sandbox       -     - Local Sandbox       -
- Checkout          -     - new work done       -     -                     -
- @ R01             -     - @ R01+              -     - @R01+               -
---------------------     -----------------------     -----------------------

Les trois repos avec un pull

---------------------     -----------------------     -----------------------
- Remote Repo       -     - Remote Repo         -     - Remote Repo         -
-                   -     - gets pushed         -     -                     -
- @ R01             -     - @ R02               -     - @ R02               -
---------------------     -----------------------     -----------------------

---------------------     -----------------------     -----------------------
- Local Repo        -     - Local Repo          -     - Local Repo          -
- pull              -     -                     -     - pull                -
- @ R01             -     - @ R01               -     - @ R02               -
---------------------     -----------------------     -----------------------

---------------------     -----------------------     -----------------------
- Local Sandbox     -     - Local Sandbox       -     - Local Sandbox       -
- Checkout          -     - new work done       -     - merged with R02     -
- @ R01             -     - @ R01+              -     - @R02+               -
---------------------     -----------------------     -----------------------

Cela m'a aidé à comprendre pourquoi une extraction est assez importante.


Pas si difficile à lire: les cases représentent l'état d'un dépôt, qui dans chaque ligne change de temps de gauche à droite après l'opération signalée dans la ligne 2 de la boîte. Les étiquettes R0n sont des balises dans git, et une balise avec un + n'est pas encore validée. Sanbox est utilisé pour votre dossier de travail, qui est différent du dossier repo, où les éléments validés sont stockés.
user1708042

96

La différence entre GIT Fetch et GIT Pull peut être expliquée par le scénario suivant: (en gardant à l'esprit que les images parlent plus fort que les mots !, j'ai fourni une représentation picturale)

Prenons un exemple que vous travaillez sur un projet avec les membres de votre équipe. Donc, ils seront une branche principale du projet et tous les contributeurs doivent le fourcher à leur propre référentiel local, puis travailler sur cette branche locale pour modifier / ajouter des modules, puis repousser vers la branche principale.

Ainsi, l' état initial des deux branches lorsque vous avez bifurqué le projet principal sur votre référentiel local sera comme ceci - ( A, Bet Cles modules sont-ils déjà terminés du projet)

entrez la description de l'image ici

Maintenant, vous avez commencé à travailler sur le nouveau module (supposons D ) et lorsque vous avez terminé le Dmodule que vous voulez pousser à la branche principale, mais en attendant ce qui se passe est que l' un de vos coéquipiers a développé un nouveau module E, Fet modifié C.
Alors maintenant, ce qui s'est passé, c'est que votre référentiel local manque derrière la progression initiale du projet et donc pousser vos modifications vers la branche principale peut entraîner des conflits et peut provoquer un Ddysfonctionnement de votre module .

entrez la description de l'image ici

Pour éviter de tels problèmes et travailler parallèlement à l'avancement initial du projet, il existe deux façons:

1. Git Fetch - Cela téléchargera toutes les modifications qui ont été apportées au projet d'origine / branche principale qui ne sont pas présentes dans votre branche locale. Et attendra la commande Git Merge pour appliquer les modifications qui ont été récupérées à votre référentiel ou branche.

entrez la description de l'image ici

Alors maintenant, vous pouvez surveiller attentivement les fichiers avant de les fusionner dans votre référentiel. Et vous pouvez également modifierD si nécessaire en raison de Modifié C.

entrez la description de l'image ici

2. Git Pull - Cela mettra à jour votre branche locale avec la branche origine / principale, c'est-à-dire que ce qu'elle fait est une combinaison de Git Fetch et de Git Merge l'une après l'autre. Mais cela peut provoquer des conflits, il est donc recommandé d'utiliser Git Pull avec une copie propre.

entrez la description de l'image ici


1
si vous pouviez remplacer «Main Branch» par «Remote Repo», ce serait une excellente réponse.
Qibiron Who

87

Nous disons simplement:

git pull == git fetch + git merge

Si vous exécutez git pull, vous n'avez pas besoin de fusionner les données en local. Si vous exécutez git fetch, cela signifie que vous devez exécutergit merge pour obtenir le dernier code sur votre ordinateur local. Sinon, le code machine local ne serait pas modifié sans fusion.

Donc, dans Git Gui, lorsque vous récupérez, vous devez fusionner les données. La récupération elle-même n'apportera pas les modifications de code à votre section locale. Vous pouvez vérifier cela lorsque vous mettez à jour le code en récupérant une fois fetch et voyez; le code, il ne changera pas. Ensuite, vous fusionnez ... Vous verrez le code modifié.


3
Je préfère dire git pull == git fetch + git merge:)
melvynkim

2
Maisgit pull --rebase = git fetch + git rebase
Tino

83

git fetchtire le code du serveur distant vers vos branches de suivi dans votre référentiel local. Si votre télécommande est nommé origin(par défaut), ces branches sera dans origin/, par exemple origin/master, origin/mybranch-123etc. Ce ne sont pas vos succursales actuelles, ils sont locaux des copies de ces branches à partir du serveur.

git pullfait un git fetchmais fusionne également le code de la branche de suivi dans votre version locale actuelle de cette branche. Si vous n'êtes pas encore prêt pour ces changements, tout d' git fetchabord.


78

git fetchrécupérera les branches à distance afin que vous puissiez git diffou git mergeeux avec la branche courante. git pullexécutera la récupération sur le brach distant suivi par la branche actuelle, puis fusionnera le résultat. Vous pouvez utiliser git fetchpour voir s'il existe des mises à jour de la branche distante sans les fusionner avec votre branche locale.


73

Git Fetch

Vous téléchargez les modifications apportées à votre succursale locale depuis l'origine via la récupération. Fetch demande au référentiel distant tous les commits que d'autres ont effectués, mais vous n'en avez pas sur votre référentiel local. Fetch télécharge ces validations et les ajoute au référentiel local.

Git Merge

Vous pouvez appliquer les modifications téléchargées via fetch à l'aide de la commande de fusion. La fusion prendra les commits récupérés de la récupération et essaiera de les ajouter à votre branche locale. La fusion conservera l'historique de validation de vos modifications locales afin que lorsque vous partagez votre branche avec push, Git sache comment les autres peuvent fusionner vos modifications.

Git Pull

L'extraction et la fusion s'exécutent assez souvent pour créer une commande combinant les deux, tirer. Pull effectue une extraction puis une fusion pour ajouter les validations téléchargées dans votre branche locale.


51

La seule différence entre git pullet git fetchest que:

git pull tire d'une branche distante et la fusionne.

git fetch récupère uniquement à partir de la branche distante mais ne fusionne pas

ie git pull = git fetch + git merge ...


1
Et ni l'aide si git pense que vous êtes en retard par les commits et que vous pouvez "avancer rapidement", ce qui a fini par finir par rm -rfrecommencer. Stupide Git, s'il te plaît laisse-moi juste me mettre à jour pour que je puisse retourner au travail?
Chris K

47

En termes simples, si vous étiez sur le point de monter dans un avion sans connexion Internet ... avant de partir, vous pouvez simplement le faire git fetch origin <master>. Il récupérerait toutes les modifications dans votre ordinateur, mais le garderait séparé de votre développement / espace de travail local.

Dans l'avion, vous pouvez apporter des modifications à votre espace de travail local, puis le fusionner avec ce que vous avez récupéré et résoudre les conflits de fusion potentiels sans connexion à Internet. Et à moins que quelqu'un n'ait apporté de nouvelles modifications contradictoires au référentiel distant, une fois arrivé à destination, vous ferez git push origin <branch>votre café.


De ce formidable tutoriel Atlassian :

le git fetch commande télécharge les validations, les fichiers et les références d'un référentiel distant dans votre référentiel local.

La récupération est ce que vous faites lorsque vous voulez voir sur quoi tout le monde a travaillé. Elle est similaire à la mise à jour SVN en ce qu'elle vous permet de voir comment l'historique central a progressé, mais elle ne vous oblige pas à fusionner réellement les modifications dans votre référentiel. Git isole le contenu récupéré en tant que contenu local existant , il n'a absolument aucun effet sur votre travail de développement local . Le contenu récupéré doit être explicitement extrait à l'aide dugit checkout commande. Cela rend la récupération d'un moyen sûr de réviser les validations avant de les intégrer à votre référentiel local.

Lorsque le téléchargement de contenu à partir d' un référentiel à distance, git pullet les git fetchcommandes sont disponibles pour accomplir la tâche. Vous pouvez envisager git fetchla version «sûre» des deux commandes. Il téléchargera le contenu distant, mais ne mettra pas à jour l'état de fonctionnement de votre référentiel local, laissant votre travail actuel intact. git pullest l'alternative la plus agressive, il télécharge le contenu distant pour la branche locale active et s'exécute immédiatement git mergepour créer un commit de fusion pour le nouveau contenu distant. Si des modifications sont en cours, cela entraînera des conflits et déclenchera le flux de résolution des conflits de fusion.


Avec git pull:

  • Vous n'obtenez aucun isolement.
  • Cela affecte votre développement local.
  • Il n'a pas besoin d'être explicitement extrait. Parce qu'il fait implicitement a git merge.
  • Ce n'est PAS sûr. C'est agressif.
  • Contrairement à git fetchce qui n'affecte que votre .git/refs/remotes, git pull affectera à la fois votre .git/refs/remotes et .git/refs/heads/

Hmmm ... donc si je ne mets pas à jour la copie de travail avec git fetch, alors où dois-je faire les changements? Où Git Fetch stocke-t-il les nouveaux validations?

Grande question. Il le place quelque part isolé de votre copie de travail. Mais encore une fois où? Découvrons-le.

Dans le répertoire de votre projet (c'est-à-dire où vous exécutez vos gitcommandes), procédez comme suit:

  1. ls. Cela montrera les fichiers et répertoires. Rien de bien, je sais.

  2. Maintenant ls -a. Cela montrera les fichiers de points , à savoir, les fichiers commençant par .Vous pourrez alors voir un répertoire nommé: .git.

  3. Faites cd .git. Cela va évidemment changer votre répertoire.
  4. Maintenant vient la partie amusante; faire ls. Vous verrez une liste de répertoires. Nous recherchons refs. Faites cd refs.
  5. Il est intéressant de voir ce qu'il y a dans tous les répertoires, mais concentrons-nous sur deux d'entre eux. headset remotes. Utilisez aussi cdpour vérifier à l'intérieur.
  6. Tout ce git fetch que vous faites mettra à jour les éléments du /.git/refs/remotesrépertoire. Il ne mettra rien à jour dans le /.git/refs/headsrépertoire.
  7. Tout le monde git pull fera d'abord la git fetchmise à jour des éléments dans le /.git/refs/remotesrépertoire, puis fusionnera avec votre section locale et changera la tête dans le /.git/refs/headsrépertoire.

Une très bonne réponse connexe peut également être trouvée dans Où se place «git fetch»? .

Recherchez également la «notation Slash» dans le post sur les conventions de dénomination de la branche Git . Il vous aide à mieux comprendre comment Git place les choses dans différents répertoires.


Pour voir la différence réelle

Faites juste:

git fetch origin master
git checkout master

Si le maître distant a été mis à jour, vous obtiendrez un message comme celui-ci:

Your branch is behind 'origin/master' by 2 commits, and can be fast-forwarded.
  (use "git pull" to update your local branch)

Si vous ne l'avez pas fait fetchet que vous l'avez fait, git checkout mastervotre git local ne saurait pas qu'il y a 2 commits ajoutés. Et cela dirait simplement:

Already on 'master'
Your branch is up to date with 'origin/master'.

Mais c'est obsolète et incorrect. C'est parce que git vous donnera des commentaires uniquement basés sur ce qu'il sait. Il est inconscient des nouveaux commits qu'il n'a pas encore baissé ...


Existe-t-il un moyen de voir les nouvelles modifications apportées à distance tout en travaillant sur la branche localement?

Certains IDE (par exemple Xcode) sont super intelligents et utilisent le résultat d'un git fetchet peuvent annoter les lignes de code qui ont été modifiées dans la branche distante de votre branche de travail actuelle. Si cette ligne a été modifiée à la fois par des modifications locales et une branche distante, cette ligne est annotée en rouge. Ce n'est pas un conflit de fusion. Il s'agit d'un conflit de fusion potentiel . C'est un headsup que vous pouvez utiliser pour résoudre le futur conflit de fusion avant de le faire à git pullpartir de la branche distante.

entrez la description de l'image ici


Conseil amusant:

Si vous avez récupéré une branche distante, par exemple:

git fetch origin feature/123

Ensuite, cela irait dans votre répertoire télécommandes. Il n'est toujours pas disponible dans votre répertoire local. Cependant, cela simplifie votre paiement vers cette branche distante par DWIM (Faites ce que je veux dire):

git checkout feature/123

vous n'avez plus besoin de faire:

git checkout -b feature/123 origin/feature/123

Pour en savoir plus, lisez ici


1
J'aime cette réponse
Kid_Learning_C

44

Git permet d'appliquer des validations chronologiquement plus anciennes après des validations plus récentes. Pour cette raison, l'acte de transfert des validations entre les référentiels est divisé en deux étapes:

  1. Copie de nouveaux validations de la branche distante vers une copie de cette branche distante dans le référentiel local.

    (opération repo to repo) master@remote >> remote/origin/master@local

  2. Intégration de nouveaux validations à la succursale locale

    (opération repo interne) remote/origin/master@local >> master@local

Il existe deux façons de procéder à l'étape 2. Vous pouvez:

  1. Forkez la branche locale après le dernier ancêtre commun et ajoutez de nouvelles validations parallèles aux validations qui sont uniques au référentiel local, finalisées par la fusion de commit, fermant la fork.
  2. Insérez de nouvelles validations après le dernier ancêtre commun et réappliquez les validations uniques au référentiel local.

En gitterminologie, l'étape 1 est git fetch, l'étape 2 est git mergeougit rebase

git pullest git fetchetgit merge


37

Git obtient la branche de la dernière version de la télécommande vers la locale à l'aide de deux commandes:

  1. git fetch: Git va obtenir la dernière version du distant au local, mais il ne fusionne pas automatiquement.      git fetch origin master git log -p master..origin/master git merge origin/master

         Les commandes ci-dessus signifient que télécharger la dernière version de la branche principale depuis l'origine de la branche distante vers la branche principale d'origine. Et compare ensuite la branche principale locale et la branche principale d'origine. Enfin, fusionnez.

  2. git pull: Git va obtenir la dernière version de la télécommande et la fusionner dans la locale.

        git pull origin master

         La commande ci-dessus est équivalente à git fetchet git merge. En pratique, git fetchpeut - être plus sûr car avant la fusion, nous pouvons voir les changements et décider de fusionner.


37

Quelle est la difference entre git pullet git fetch?

Pour comprendre cela, vous devez d'abord comprendre que votre git local gère non seulement votre référentiel local, mais également une copie locale du référentiel distant.

git fetchmet à jour votre copie locale du référentiel distant. Par exemple, si votre référentiel distant est GitHub - vous souhaiterez peut-être récupérer toutes les modifications apportées dans le référentiel distant vers votre copie locale du référentiel distant. Cela vous permettra d'effectuer des opérations telles que comparer ou fusionner.

git pulld'autre part, apportera les modifications dans le référentiel distant à l'endroit où vous conservez votre propre code. En règle générale, git pullfera une git fetchpremière pour mettre à jour la copie locale du référentiel distant, puis il fusionnera les modifications dans votre propre référentiel de code et éventuellement votre copie de travail.


35

git pull == (git fetch + git merge)

git fetch ne change pas les branches locales.

Si vous avez déjà un référentiel local avec une configuration à distance pour le projet souhaité, vous pouvez récupérer toutes les branches et balises de la télécommande existante à l'aide de git fetch. ... Fetch n'apporte aucune modification aux branches locales, vous devrez donc fusionner une branche distante avec une branche locale appariée pour incorporer les nouvelles modifications fetch. de github


34

Essayer d'être clair et simple.

La commande git pull est en fait une commande shortcutfor git fetch suivie de la commande git merge ou de la commande git rebase selon votre configuration. Vous pouvez configurer votre référentiel Git de sorte que git pull soit une extraction suivie d'une rebase.


33

Une représentation graphique simple pour les débutants,

entrez la description de l'image ici

ici,

git pull  

va récupérer le code du référentiel et rebaser avec votre local ... dans git pull il y a possibilité de création de nouveaux commits.

mais en ,

git fetch

va récupérer le code du référentiel et nous devons le rebaser manuellement en utilisant git rebase

par exemple: je vais récupérer du maître du serveur et le rebaser dans mon maître local.

1) git pull (le rebase se fera automatiquement):

git pull origin master

ici l' origine est votre maître repo à distance est votre branche

2) git fetch (besoin de rebaser manuellement):

git fetch origin master

il récupérera les modifications du serveur depuis l'origine. et il sera dans votre section locale jusqu'à ce que vous le rebasiez par vous-même. nous devons résoudre les conflits manuellement en vérifiant les codes.

git rebase origin/master

cela rebasera le code en local. avant cela, assurez-vous que vous êtes dans la bonne branche.


Beau graphique, mais vous voudrez peut-être expliquer pourquoi vous utilisez "rebase" lorsque le graphique dit "fusionner".
Guntram Blohm prend en charge Monica

2
merge représentera une autre validation de branche et produira une nouvelle validation qui contient des validations comme référence. mais rebase répliquera les commits d'une autre branche, il ne créera pas de nouveau commit plutôt qu'il ne se répliquera
Mohideen bin Mohammed

33

En fait, Git conserve une copie de votre propre code et du référentiel distant.

La commande git fetchmet à jour votre copie locale en obtenant les données du référentiel distant. La raison pour laquelle nous en avons besoin est que quelqu'un d'autre a peut-être apporté des modifications au code et que vous souhaitez vous tenir à jour.

La commande git pullapporte les modifications dans le référentiel distant à l'endroit où vous conservez votre propre code. Normalement, git pullcela se fait en faisant un 'git fetch' d'abord pour mettre à jour la copie locale du référentiel distant, puis il fusionne les modifications dans votre propre référentiel de code et éventuellement votre copie de travail.

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.