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

Question

Note du modérateur: Étant donné que cette question a déjà eu soixante-sept réponses affichées (certaines supprimées), demandez-vous si vous êtes contribuant à quelque chose de nouveau _ avant d’en poster un autre.

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

Greg Hewgill · Accepted Answer

Dans les termes les plus simples, git pull fait un git fetch suivi d'un git merge.

Vous pouvez créer un git fetch à tout moment pour mettre à jour vos branches de télé-suivi sous refs/remotes/<remote>/.

Cette opération ne change jamais aucune de vos propres succursales locales sous refs/heads et vous pouvez le faire en toute sécurité sans changer votre copie de travail. J'ai même entendu parler de personnes exécutant git fetch régulièrement dans un travail cron en arrière-plan (bien que cela ne soit pas recommandé).

Un git pull vous permet de mettre à jour une branche locale avec sa version distante, tout en mettant à jour vos autres branches de suivi à distance.

Documentation Git: git pull

Mouna Cheikhna · Answer

Lorsque vous utilisez pull, Git essaie de faire votre travail automatiquement pour vous. Il est sensible au contexte}, donc Git fusionnera tous les commits extraits dans la branche dans laquelle vous travaillez actuellement. pull fusionne automatiquement les commits sans vous permettre de les réviser au préalable}. Si vous ne gérez pas étroitement vos succursales, vous risquez d’être fréquemment en conflit.
Lorsque vous fetch, Git recueille tous les commits 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}. Ceci est particulièrement utile si vous devez garder votre référentiel à jour, mais travaillez sur quelque chose qui pourrait casser si vous mettez à jour vos fichiers. Pour intégrer les commits dans votre branche principale, utilisez merge.

MikeD · Answer

Il est important d’opposer la philosophie de conception de git à la philosophie d’un outil de contrôle de source plus traditionnel tel que 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 extraire le code du serveur, le travailler, puis le renvoyer sur le 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é ne nécessitant pas de référentiel central (bien que vous puissiez certainement en utiliser un si vous le souhaitez). Aussi, 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 de manière à ce que même les personnes disposant d’un lien peu fiable puissent échanger du code par courrier électronique. 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 ainsi qu'un référentiel local supplémentaire reflétant 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 devrez envoyer les modifications à quelqu'un d'autre, git pourra les transférer sous forme d'un ensemble de modifications à partir d'un moment connu du référentiel distant.

git fetchest la commande qui dit "apporte ma copie locale du référentiel distant à jour".
git pulldit "apporte les modifications dans le référentiel distant à l'endroit où je conserve mon propre code."

Normalement,git pullfait cela en effectuant ungit fetchpour mettre à jour 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.

Il faut 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 seconde copie est votre copie de travail sur laquelle vous éditez et construisez. La troisième copie est votre copie locale "en cache" d'un référentiel distant.

Contango · Answer

Voici l'image d'Oliver Steele montrant comment tout cela s'emboîte }:

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...

mepster · Answer

Un cas d'utilisation de git fetch est que ce qui suit vous indiquera tout changement dans la branche distante depuis votre dernier extraction ... afin que vous puissiez vérifier avant d'effectuer une extraction réelle, ce qui pourrait modifier les fichiers de votre branche actuelle et de votre copie de travail.

git fetch git diff ...Origin

Gerardo · Answer

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

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

lorsque vous commencez à travailler et que vous effectuez des commits, vous avancez le pointeur principal sur HEAD + vos commits. Mais le pointeur Origine/Maître pointe toujours sur ce que vous avez cloné.

Donc, la différence sera:

Si vous faites un git fetch, il récupérera simplement toutes les modifications dans le référentiel distant ( GitHub ) et déplacera le pointeur Origine/Maître sur HEAD. Pendant ce temps, votre directeur de succursale local continuera à indiquer où il se trouve.
Si vous faites un git pull, il va essentiellement chercher (comme expliqué précédemment) et fusionner toutes les nouvelles modifications apportées à votre branche principale et déplacer le pointeur sur HEAD.

thedarkpassenger · Answer

Parfois, une représentation visuelle aide.

Snowcrash · Answer

Brièvement

git fetch est similaire à pull mais ne fusionne pas. c’est-à-dire qu’il récupère les mises à jour distantes (refs et objects) mais votre adresse locale reste la même (c’est-à-dire que Origin/master est mis à jour mais que master reste identique).

git pull descend d'une télécommande et fusionne instantanément.

Plus

git clone clone un repo.

git rebase enregistre dans une zone temporaire des éléments de votre branche actuelle qui ne se trouve pas dans la branche en amont. Votre branche est maintenant la même qu'avant de commencer vos modifications. Ainsi, git pull -rebase enregistrera les modifications à distance, rembobinera votre branche locale, repassera vos modifications au-dessus de votre branche actuelle une par une jusqu'à ce que vous soyez à jour.

De plus, git branch -a vous montrera exactement ce qui se passe dans toutes vos succursales - locales et distantes.

Ce blog a été 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 mettre à jour ceci pour montrer comment vous l'utiliseriez réellement dans la pratique.

Mettez à jour votre référentiel local à partir de la télécommande (mais ne fusionnez pas):
```
git fetch 
```
Après avoir téléchargé les mises à jour, voyons les différences:
```
git diff master Origin/master 
```
Si vous êtes satisfait de ces mises à jour, fusionnez:
```
git pull 
```

Remarques:

Étape 2: Pour plus d'informations sur les différences entre les télécommandes locales et distantes, voir: Comment comparer une branche git locale à sa branche distante?

A l’étape 3: il est probablement plus précis (par exemple, sur un dépôt rapide) de faire un git rebase Origin ici. Voir @Justin Ohms commenter dans une autre réponse.

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

Vinko Vrsalovic · Answer

 git-pull - Lit et fusionne avec un autre référentiel ou une branche locale SYNOPSIS git pull… DESCRIPTION Lance git-fetch avec les paramètres donnés, et appelle git-merge pour fusionner les têtes récupérées dans la branche en cours. Avec --rebase, appelle git-rebase Au lieu de git-merge . Notez que vous pouvez utiliser. (répertoire courant) en tant que <référentiel> à extraire du référentiel local - cela est utile lors de la fusion de branches locales dans la branche actuelle . Notez également que les options destinées à git-pull 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 allez chercher si vous voulez simplement «codez», car une personne a marqué certains articles ici.

Antonio Bardazzi · Answer

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

Ceci est un exemple pour un référentiel distant appelé Origin et une branche appelée master surveillant la branche distante Origin/master:

git checkout master git fetch git diff Origin/master git rebase Origin master

jfmercer · Answer

La réponse simple et rapide est que git pull est tout simplement git fetch suivi de git merge.

Il est très important de noter que git pull va fusionner automatiquement que vous le vouliez ou non. Bien entendu, cela pourrait entraîner des conflits de fusion. Supposons 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 branche locale en conséquence.

En plus de tirer et de pousser, certains workflows implique 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 ne sachiez vraiment ce que vous faites, je déconseillerais cela. Cet avertissement provient de la page man pour git-pull, version 2.3.5:

C'est un mode de fonctionnement potentiellement dangereux. Il réécrit l’histoire, ce qui augure mal lorsque vous publiez cette histoire déjà. N'utilisez cette option que si vous avez lu git-rebase (1) soigneusement.

Alireza · Answer

OK, voici quelques informations sur git pull et git fetch, afin que vous puissiez comprendre les différences réelles ... en quelques mots simples, fetch récupère les données les plus récentes, mais pas les modifications de code. pour modifier le code de votre branche locale actuelle, mais pull obtenir les modifications de code et le fusionner avec votre branche locale, lisez la suite pour obtenir plus de détails sur chacun:

aller chercher

Il téléchargera tous les refs et objects ainsi que toutes les nouvelles branches dans votre référentiel local ...

Récupérer des branches et/ou des tags (collectivement, "refs") d'un ou plusieurs autres dépôts, ainsi que les objets nécessaires pour compléter leur des histoires. Les branches de suivi à distance sont mises à jour (voir la description Ci-dessous pour savoir comment contrôler ce problème).

Par défaut, toute balise pointant dans les historiques recherchés est également cherché; l’effet est de récupérer des balises qui pointent vers des branches qui vous êtes intéressé par. Ce comportement par défaut peut être changé en utilisant les options --tags ou --no-tags ou en configurant remote..tagOpt. En utilisant un refspec qui récupère les balises explicitement, vous pouvez récupérer des tags qui ne pointent pas dans les branches qui vous intéressent dans aussi bien.

git fetch peut extraire d'un seul référentiel nommé ou d'une URL, ou à partir de plusieurs dépôts à la fois si est donné et il y a un télécommandes. entrée dans le fichier de configuration. (Voir git-config 1 ).

Si aucune télécommande n'est spécifiée, par défaut, la télécommande d'origine sera utilisé, sauf s’il existe une branche en amont configurée pour le courant branche.

Les noms des références extraites, ainsi que les noms d'objet ils pointent sur, sont écrits dans .git/FETCH_HEAD. Cette information peut être utilisé par des scripts ou d'autres commandes git, telles que git-pull.

git pull

Il appliquera les modifications de remote à la branche current dans le répertoire 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 fusion de FETCH_HEAD.

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

devrait être le nom d'un référentiel distant tel que transmis à git-fetch 1 . pouvez nommer une référence distante arbitraire (par exemple, le nom d'une balise) ou même une collection de références avec la référence correspondante branches de suivi à distance (par exemple, refs/heads/: refs/remotes/Origin /), mais il s’agit généralement du nom d’une branche du référentiel distant.

Les valeurs par défaut pour et sont lues à partir du fichier Configuration "distante" et "fusionnée" pour la branche actuelle définie par git-branch --track.

Je crée également le visual ci-dessous pour vous montrer comment git fetch et git pull travaillent ensemble ...

th3sly · Answer

enter image description here

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

git fetch "télécharge" simplement les modifications de la télécommande vers votre référentiel local. git pull télécharge les modifications et les fusionne dans votre branche actuelle. "Dans son mode par défaut, git pull est un raccourci pour git fetch suivi de git merge FETCH_HEAD."

Sazzad Hissain Khan · Answer

Prime:

En parlant de tirer et chercher dans les réponses ci-dessus, je voudrais partager un tour intéressant,

`git pull --rebase`

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

Avant de transmettre vos nouveaux commits au serveur, essayez cette commande. Elle synchronisera automatiquement les dernières modifications apportées au serveur (avec une récupération + fusion) et placera votre validation en haut de la liste dans le journal git. Pas besoin de s'inquiéter de l'extraction/fusion manuelle.

Vous trouverez des détails sur: http://gitolite.com/git-pull--rebase

Justus Romijn · Answer

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 tout à fait sûr que tout est correct, alors veuillez 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 commits et messages sans essayer de les faire passer sur le réseau)
Commentaires à propos de l'état de votre référentiel local (par exemple, j'utilise SourceTree d'Atlassian, ce qui me donnera une ampoule indiquant si je commets d'avance ou de retard par rapport à l'origine. Cette information peut être mise à jour avec un GIT FETCH ).

pn1 dude · Answer

J'ai eu du mal avec cela aussi. En fait, je suis arrivé ici avec une recherche google de la même question. En lisant toutes ces réponses, j’ai fini par avoir une image dans ma tête et j’ai décidé d’essayer de voir l’état actuel des 2 dépôts, un bac à sable et des actions effectuées au fil du temps tout en regardant leur version. Alors voici ce que je suis venu avec. S'il vous plaît, corrigez-moi si je me suis planté ailleurs.

Les trois pensions avec un chercher:

--------------------- ----------------------- ----------------------- - 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 un fetch est assez important.

Aman Tiwari · Answer

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

Prenons un exemple montrant que vous travaillez sur un projet avec les membres de votre équipe. Il s’agit donc d’une branche principale du projet et tous les contributeurs doivent le bifurquer vers leur propre référentiel local, puis travailler sur cette branche locale pour modifier/ajouter des modules, puis revenir à la branche principale.

Donc, L'état initial des deux branches lorsque vous avez créé le projet principal sur votre référentiel local sera comme ceci- (A, B et C sont des modules déjà terminés du projet)

Maintenant, vous avez commencé à travailler sur le nouveau module (supposez D) et lorsque vous avez terminé le module D, vous voulez le transférer dans la branche principale. Mais entre-temps, un de vos coéquipiers a développé le nouveau module E, F et modifié C.
Alors maintenant, ce qui s’est passé, c’est que votre référentiel local manque de la progression du projet et que, par conséquent, le fait de modifier vos modifications dans la branche principale peut entraîner un conflit et entraîner un dysfonctionnement de votre module D.

Pour éviter de tels problèmes et travailler en parallèle avec la progression initiale du projet, il existe deux manières:

1. Git Fetch- Ceci téléchargera toutes les modifications apportées au projet Origin/Main qui ne sont pas présentes dans votre branche locale. Et attendra que la commande Git Merge applique les modifications extraites à votre référentiel ou à votre branche.

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

2. Git Pull- Ceci mettra à jour votre branche locale avec l'origine/branche principale, c'est-à-dire qu'il combine Git Fetch et Git fusionnent l'un après l'autre . Mais cela peut entraîner des conflits. , il est donc recommandé d’utiliser Git Pull avec une copie vierge.

Selvamani · Answer

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écuter git merge pour obtenir le dernier code sur votre ordinateur local. Sinon, le code machine local ne serait pas modifié sans fusion.

Ainsi, dans Git Gui, lorsque vous récupérez, vous devez fusionner les données. La recherche elle-même ne modifiera pas le code chez votre section locale. Vous pouvez vérifier cela lorsque vous mettez à jour le code en récupérant Une fois, extrayez et voyez; le code ne changera pas. Ensuite, vous fusionnez ... Vous verrez le code modifié.

Michael Durrant · Answer

git fetch extrait le code du serveur distant dans vos branches de suivi dans votre référentiel local. Si votre télécommande s'appelle Origin (valeur par défaut), ces branches se trouveront dans Origin/, par exemple Origin/master, Origin/mybranch-123, etc. Ce ne sont pas vos branches actuelles, elles sont des copies locales de ces branches à partir du serveur.

git pull effectue un git fetch mais ensuite aussi fusionne le code de la branche de suivi dans votre version locale actuelle de cette branche. Si vous n'êtes pas encore prêt pour cela, changez d'abord git fetch.

ntanase · Answer

git fetch va récupérer les branches distantes afin que vous puissiez git diff ou git merge avec la branche actuelle. git pull lancera la recherche sur le bras distant suivi par la branche actuelle, puis fusionnera le résultat. Vous pouvez utiliser git fetch pour voir s'il existe des mises à jour de la branche distante sans les fusionner nécessairement avec votre branche locale.

Pinkesh Sharma · Answer

Git Fetch

Vous téléchargez les modifications apportées à votre branche locale depuis Origin via fetch. Fetch demande au référentiel distant tous les commits que d'autres ont effectués mais que vous n'avez pas sur votre référentiel local. Fetch télécharge ces commits 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 extraits de fetch 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

La récupération et la fusion vont assez souvent ensemble pour qu'une commande combinant les deux, pull, ait été créée. Pull effectue une extraction, puis une fusion pour ajouter les validations téléchargées dans votre branche locale.

Rohitashv Singhal · Answer

La seule différence entre git pull et git fetch est la suivante:

git pull extrait une branche distante et la fusionne.

git fetch extrait uniquement de la branche distante mais ne fusionne pas

c'est-à-dire git pull = git fetch + fusion de git ...

Pawel Furmaniak · Answer

Git permet d'appliquer des commits chronologiquement plus anciens après des commits plus récents . De ce fait, le transfert de commits entre des référentiels est divisé en deux étapes:

Copier les nouveaux commits d'une branche distante vers une copie de cette branche distante dans le référentiel local.

(repo to repo operation) master@remote >> remote/Origin/master@local
Intégration de nouveaux commits à la branche locale

(opération dans le repo) remote/Origin/master@local >> master@local

Il y a deux façons de faire l'étape 2. Vous pouvez:

Branche la branche locale après le dernier ancêtre commun et ajoute de nouveaux commits parallèlement aux commits uniques au référentiel local, finalisés par la fusion de la validation et la fermeture du fork.
Insérez les nouveaux commits après le dernier ancêtre commun et réappliquez les commits propres au référentiel local.

Dans la terminologie git, l'étape 1 correspond au git fetch, l'étape 2 au git merge ou au git rebase

git pull est git fetch et git merge

Donal · Answer

Quelle est la différence entre git pull et 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 fetch met à 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 sur votre copie locale, le référentiel distant. Cela vous permettra d'effectuer des opérations telles que la comparaison ou la fusion.

git pull, en revanche, réduira les modifications dans le référentiel distant pour conserver votre propre code. Généralement, git pull fait d'abord un git fetch 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.

Marcus Thornton · Answer

Git obtient la branche de la dernière version de la télécommande au local en utilisant deux commandes:

git fetch: Git va obtenir la dernière version de distant en local, mais ne se 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 d’origine à partir de la branche distante vers la branche principale d’origine. Et compare ensuite la branche maître locale et la branche maître d’origine. Enfin, fusionnez.
git pull: Git va récupérer la dernière version de la télécommande et se fondre dans la version locale.

git pull Origin master

La commande ci-dessus équivaut à git fetch et git merge. En pratique, git fetch est peut-être plus sécurisé, car avant la fusion, nous pouvons voir les modifications et décider de la fusion.

Iggy · Answer

git pull == (git fetch + fusion de git)

git fetch ne change pas en branches locales.

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

Pokemon · Answer

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

La commande git fetch met à jour votre copie locale en récupérant les données du référentiel distant. Nous avons besoin de cela parce que quelqu'un d'autre a peut-être apporté des modifications au code et que vous souhaitez rester à jour.

La commande git pull apporte les modifications dans le référentiel distant là où vous conservez votre propre code. Normalement, git pull le fait en commençant par un "git fetch" 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.

montells · Answer

Essayer d'être clair et simple.

La commande git pull est en fait une shortcut pour git fetch suivie de la fusion git ou de la commande git rebase en fonction de votre configuration. Vous pouvez configurer votre référentiel Git de sorte que git pull soit une extraction, suivie par une base.

Mohideen ibn Mohammed · Answer

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

ici,

git pull

récupérera le code du référentiel et se rebase avec votre section locale ... avec git pull, il est possible que de nouveaux commits soient créés.

mais en ,

aller chercher

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

par exemple: je vais chercher à partir du serveur maître et le rebase dans mon maître local.

1) git pull (rebase sera fait automatiquement):

git pull Origin master

ici Origin est votre référentiel distant master est votre branche

2) git fetch (besoin de rebaser manuellement):

git fetch Origin master

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

git rebase Origin/master

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

Saqib R. · Answer

git pull = git fetch + git merge

Zhenxiao Hao · Answer

From Pro Git § 2.5 Bases de Git - Travailler avec des télécommandes: aller chercher et extraire vos télécommandes :

Il est important de noter que la commande fetch extrait les données dans votre référentiel local. Elle ne le fait pas fusionnez-le automatiquement avec n’importe quel de vos travaux ou modifiez ce que vous êtes travaille actuellement sur. Vous devez le fusionner manuellement dans votre travail Quand tu es prêt.

Si vous avez une branche configurée pour suivre une branche distante, vous pouvez utiliser le fichier git pull commande pour extraire automatiquement puis fusionner un .__ distant. branchez dans votre branche actuelle. Cela peut être plus facile ou plus flux de travail confortable pour vous; et par défaut, la commande git clone configure automatiquement votre branche maître locale pour suivre la télécommande branche principale sur le serveur à partir duquel vous avez cloné (en supposant que la télécommande possède une branche principale ). Lancer git pull récupère généralement les données du fichier serveur à partir duquel vous avez initialement cloné et tente automatiquement de le fusionner dans le code sur lequel vous travaillez actuellement.

Animesh Sharma · Answer

git pull

Il exécute deux fonctions en utilisant une seule commande.

Il récupère toutes les modifications apportées à la branche distante, puis les fusionne dans votre branche locale. Vous pouvez également modifier le comportement de pull en passant --rebase. La différence entre merge et rebase peut être lue ici

git fetch

Git Fetch ne fait que la moitié du travail de git pull. Il apporte simplement les modifications à distance dans votre référentiel local mais ne les applique pas à vos succursales. Vous devez appliquer ces modifications explicitement. Cela peut être fait comme suit:

git fetch git rebase Origin/master

g24l · Answer

Il faut garder à l'esprit la nature de git. Vous avez des télécommandes et vos succursales locales (pas nécessairement les mêmes). En comparaison avec d'autres systèmes de contrôle de source, cela peut être un peu déroutant.

Habituellement, lorsque vous extrayez une télécommande, une copie locale est créée pour la suivre.

git fetch fonctionnera avec la branche distante et mettra à jour vos informations.

C'est en fait le cas si d'autres SWE travaillent dans la même branche, et rarement dans des scénarios de petite taille - une branche - un projet.

Votre travail sur la branche locale est toujours intact. Afin d'apporter les modifications à votre branche locale, vous devez fusionner/redéfinir les modifications à partir de la branche distante.

git pull fait exactement ces deux étapes (c'est-à-dire --référer pour rebaser au lieu de fusionner)

Si votre historique local et l'historique distant ont des conflits, vous serez obligé de faire la fusion lors d'un git Push pour publier vos modifications.

Ainsi, cela dépend vraiment de la nature de votre environnement de travail et de l'expérience à utiliser.

Nan Xiao · Answer

De git aide-mémoire :

git fetch <remote> // Download all changes from <remote>, but don't integrate into HEAD git pull <remote> <branch> // Download changes and directly merge/integrate into HEAD

Pragyaditya Das · Answer

D'après ce que j'ai compris,

Git pull - Descend d'une télécommande spécifiée (spécifiée par l'utilisateur) et la fusionnera instantanément dans une branche sur laquelle nous nous trouvons actuellement. Il s’agit essentiellement d’un mélange de commandes d’extraction et de fusion.

Git Fetch - Identique à Pull, mais ne permet pas la fusion Vous pouvez donc surveiller attentivement les fichiers avant de les fusionner.

Cette URL doit aider à mieux comprendre: La différence entre git pull, git fetch et git clone (et git rebase).

miva2 · Answer

En termes simples et brefs:

git fetch: Regardez s'il y a de nouvelles choses.

git pull: Prenez le nouveau matériel et mettez-le sur votre matériel.

ishandutta2007 · Answer

Je pense que la plupart des réponses ont très bien répondu à la différence. Je voudrais souligner quand utiliser qui à la place.

La récupération peut être utile lorsque vous souhaitez obtenir la mise à jour des autres développeurs, mais que vous souhaitez continuer votre travail sans entrave. Les personnes qui souhaitent souvent travailler en mode hors connexion et travailler utilisent fetch pour obtenir la dernière mise à jour jusqu'à ce qu'elle soit en ligne. Plus tard, quand il/elle est à l'aise avec ses changements, fusionne ceux de la branche dans son espace de travail.

Alors que les personnes qui travaillent en ligne sont très sûres de leurs modifications et souhaitent obtenir immédiatement le dernier code et merge utilise pull. J'utilise rarement fetch car, pour vérifier les dernières mises à jour, je les vérifie via le site Web de GitHub et je travaille toujours hors ligne. Comme je l'ai mentionné, vous pouvez utiliser le scénario ci-dessus.

Andrei Todorut · Answer

Git Fetch

Vous aide à connaître les dernières mises à jour à partir d'un git repository. Supposons que vous travailliez dans une équipe utilisant GitFlow, où une équipe travaille sur plusieurs branches (fonctionnalités). Avec git fetch --all command, vous pouvez être informé de toutes les nouvelles branches au sein de repository.

git fetch est principalement utilisé avec git reset. Par exemple, vous souhaitez rétablir toutes vos modifications locales dans l'état actuel du référentiel.

git fetch --all // get known about latest updates git reset --hard Origin/[branch] // revert to current branch state

Git pull

Cette commande met à jour votre branch avec l’état actuel repository branch. Continuons avec GitFlow. La fonctionnalité multiple branches était merged à develop branche et lorsque vous souhaitez développer de nouvelles fonctionnalités pour le projet, vous devez accéder à la commande branch develop et faire un git pull pour obtenir l'état actuel de develop branch

Documentation pour GitFlow https://Gist.github.com/peterdeweese/4251497

Arnel Lenteria · Answer

Git fetch synchronise le catalogue du référentiel distant avec votre local. Il ne fusionnera pas les modifications de fichier/code de la télécommande vers votre branche locale.

Git pull télécharge les modifications relatives à votre branche locale actuelle, puis les fusionne.

Honey · Answer

De ce génial Attlassian tutorial:

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

Aller chercher est ce que vous faites quand vous voulez voir ce que tout le monde else a travaillé Semblable à svn update, il vous permet de voir l’évolution de l’historique central, mais ne vous oblige pas à fusionner les modifications dans votre référentiel. Git isole le contenu extrait en tant que contenu local existant, il a absolument aucun effet sur votre travail de développement local}. Le contenu récupéré doit être explicitement extrait à l'aide de la commande git checkout. Cela fait de la récupération un moyen sûr de vérifier les validations avant de les intégrer à votre référentiel local.

Lors du téléchargement de contenu depuis un dépôt distant, les commandes git pull et git fetch sont disponibles pour accomplir la tâche. Vous pouvez considérer git fetch comme la version "sécurisée" 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 ainsi votre travail actuel intact. git pull est l'alternative la plus agressive, il téléchargera le contenu distant pour la branche locale active et exécutera immédiatement git merge pour créer un commit de fusion pour le nouveau contenu distant. Si vous avez des modifications en attente en cours, cela provoquera des conflits et lancera 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 un git merge.
C'est fondamentalement pas sûr. C'est agressif.
Contrairement à git fetch où cela affecte uniquement votre .git/refs/remotes, git pull affectera aussi bien votre .git/refs/remotes et .git/refs/heads/.

Hmmm ... alors si je ne mets pas à jour la copie de travail avec `git fetch`, alors où vais-je apporter des modifications? Où git fetch stocke-t-il les nouveaux commits?

Excellente question. Cela le place quelque part à l’écart de votre copie de travail. Mais encore où? Découvrons-le.

Dans votre répertoire de projet (c’est-à-dire où vous faites vos commandes git), faites:

ls. Cela montrera les fichiers et répertoires. Rien de cool, je sais.
Maintenant, faites ls -a. Cela affichera point fichiers ie fichiers commençant par . Vous pourrez alors voir un répertoire nommé: .git.
Faites cd .git. Cela va évidemment changer votre répertoire.
Maintenant vient la partie amusante; faire ls. Vous verrez une liste de répertoires. Nous cherchons refs. Faites cd refs.
C'est intéressant de voir ce qu'il y a dans tous les répertoires, mais concentrons-nous sur deux d'entre eux. heads et remotes. Utilisez cd pour vérifier à l'intérieur également.
TOUT __ git fetch que vous ferez mettra à jour les éléments du répertoire /.git/refs/remotes. Il ne mettra rien à jour dans le répertoire /.git/refs/heads.
TOUT __ git pull fera d’abord le git fetch, mettra à jour les éléments du répertoire /.git/refs/remotes, puis fusionnera avec votre local, puis changera l’en-tête dans le répertoire /.git/refs/heads.

On peut également trouver une très bonne réponse connexe Où se situe 'git fetch'?

Recherchez également la "notation par barre oblique" dans Conventions de dénomination des branches Git post.

Chetabahana · Answer

Comme répondu, il ne fait aucun doute que git-pull est git-fetch plus fusion. Je tiens à souligner que:

quand vous voulez vérifier avant de fusionner, vous devriez utiliser git-fetch suivi de git-pull.

Sur cronjob il est utile de le faire comme indiqué dans le script ci-dessous:

#!/bin/sh git fetch upstream if [ `git rev-list HEAD...upstream/master --count` -eq 0 ] then echo "all the same, do nothing" else echo "update exist, let's pull" git pull upstream master git Push Origin master fi

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

aller chercher

git pull

Prime:

git pull --rebase

Hmmm ... alors si je ne mets pas à jour la copie de travail avec git fetch, alors où vais-je apporter des modifications? Où git fetch stocke-t-il les nouveaux commits?

`git pull --rebase`

Hmmm ... alors si je ne mets pas à jour la copie de travail avec `git fetch`, alors où vais-je apporter des modifications? Où git fetch stocke-t-il les nouveaux commits?