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

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.

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

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.

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

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

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

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.

Parfois, une représentation visuelle aide.

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/

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.

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

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

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

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

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

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

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.

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)

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 .

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.

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.

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.

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

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.

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.

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.

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

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.

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

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

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.

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.

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

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.

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

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.

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.