Quelles sont les différences entre git pull y git fetch ?
En termes simples, git pull fait un git fetch suivi d'un git merge .
Vous pouvez faire une git fetch à tout moment pour mettre à jour vos branches de suivi à distance sous refs/remotes/<remote>/ . Cette opération ne modifie en aucun cas vos propres branches locales sous refs/heads et il est possible de le faire en toute sécurité sans modifier votre copie de travail. J'ai même entendu parler de personnes exécutant git fetch périodiquement dans une tâche cron en arrière-plan (bien que je ne recommande pas de le faire).
A git pull est ce que vous feriez pour mettre à jour une branche locale avec sa version distante, tout en mettant à jour vos autres branches de suivi à distance.
Extrait de la documentation Git pour git pull :
Dans son mode par défaut,
git pullest l'abréviation degit fetchsuivi degit merge FETCH_HEAD.
"Un "git pull" est ce que vous feriez pour mettre à jour votre dépôt" <- la mise à jour du dépôt n'est-elle pas déjà faite par fetch ? ne voulez-vous pas dire qu'elle met à jour vos branches locales avec les branches 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 : Oui, c'est bizarrement formulé. git pull se fondra toujours dans le branche actuelle . Vous sélectionnez donc la branche que vous souhaitez retirer de et il l'intègre dans la branche courante. Les de peut être locale ou distante ; il peut même s'agir d'une succursale distante qui n'est pas une succursale enregistrée. git remote (c'est-à-dire que vous transmettez une URL à la fonction git pull ligne de commande).
Lorsque vous utilisez pull Git tente de les fusionner automatiquement. Il est sensible au contexte afin que Git fusionne les commits tirés dans la branche sur laquelle vous travaillez actuellement. pull fusionne automatiquement les commits sans vous permettre de les examiner au préalable . Si vous ne gérez pas soigneusement vos branches, vous risquez d'être confronté à des conflits fréquents.
Lorsque vous fetch Git rassemble tous les commits de la branche cible qui n'existent pas dans votre branche actuelle et les stocke dans votre dépôt local . Cependant, il ne les fusionne pas avec votre branche actuelle . Ceci est particulièrement utile si vous devez garder votre dépôt à jour, mais que vous travaillez sur quelque chose qui risque de se casser si vous mettez à jour vos fichiers. Pour intégrer les commits dans votre branche actuelle, vous devez utiliser merge par la suite.
Tout à fait d'accord, excellent commentaire. C'est pourquoi je déteste git pull. Quand serait-il judicieux de laisser un outil de révision modifier le code à votre place ? 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 ?
Je ne suis pas sûr d'avoir bien compris. Dites-moi si j'ai raison : Disons que j'ai deux branches, master et test. test est une branche sur laquelle je travaille pour expérimenter quelque chose. Si je fais git fetch, cela met à jour master avec la branche cible. Si je fais git pull, il essaie de mettre à jour test avec la branche cible. Est-ce que c'est correct ? Si ce n'est pas le cas, je pense que je n'ai pas compris ce que signifie "dépôt local" - j'ai supposé qu'il s'agissait de mon master local.
@elexhobby en bref, git fetch ne fait que mettre à jour votre .git/ (AKA : local repository) et rien en dehors de .git/ (AKA : arbre de travail). Il ne modifie pas vos branches locales, et ne touche pas à l'arborescence de travail. master soit. Il touche remotes/origin/master (voir git branch -avv ). Si vous avez plusieurs télécommandes, essayez git remote update . Il s'agit d'un git fetch pour toutes les télécommandes en une seule commande.
Il est important de comparer la philosophie de conception de git à celle d'un outil de contrôle de source plus traditionnel comme SVN.
Subversion a été conçu et réalisé selon un modèle client/serveur. Il y a un dépôt unique qui est le serveur, et plusieurs clients peuvent récupérer du code sur le serveur, travailler dessus, puis le renvoyer au serveur. L'hypothèse est que le client peut toujours contacter le serveur lorsqu'il a besoin d'effectuer une opération.
Git a été conçu pour supporter un modèle plus distribué, sans avoir besoin d'un dépôt central (bien que vous puissiez 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 des personnes sur un lien peu fiable puissent échanger du code par courrier électronique, même. Il est possible de travailler complètement déconnecté et de graver un CD pour échanger du code via git.
Afin de supporter ce modèle, git maintient un dépôt local avec votre code ainsi qu'un dépôt local supplémentaire qui reflète l'état du dépôt distant. En gardant une copie du dépôt distant localement, git peut déterminer les changements nécessaires même si le dépôt distant n'est pas accessible. Plus tard, lorsque vous devez envoyer les modifications à quelqu'un d'autre, git peut les transférer comme un ensemble de modifications à partir d'un point dans le temps connu du dépôt distant.
git fetch est la commande qui dit "mettre à jour ma copie locale du référentiel distant".
git pull dit "apporter les changements dans le dépôt distant à l'endroit où je garde mon propre code".
Normalement git pull Pour ce faire, il effectue une git fetch pour mettre à jour la copie locale du dépôt distant, puis fusionner les modifications dans votre propre dépôt de code et éventuellement dans votre copie de travail.
Il faut donc garder à l'esprit qu'il y a souvent au moins trois exemplaires d'un projet sur votre poste de travail. Une copie est votre propre dépôt avec votre propre historique de livraisons. La seconde copie est votre copie de travail où vous éditez et construisez. La troisième copie est votre copie locale "en cache" d'un dépôt distant.
Techniquement, les dépôts locaux et distants sont en réalité une seule et même chose. Dans Git, un dépôt est un fichier DAG d'engagements pointant vers leurs parents. Les branches ne sont, techniquement, rien d'autre que des noms significatifs de commits. La seule différence entre les branches locales et distantes est que les branches distantes sont préfixées par le préfixe remoteName/ Git à partir de la base est une très bonne lecture. Une fois que l'on a compris comment fonctionne Git - et il est magnifiquement simple En fait, tout a un sens.
Merci beaucoup pour cette explication. Je n'avais pas vraiment compris jusqu'à présent que Git avait été conçu pour éviter d'avoir un dépôt central. Tout le monde dit toujours "DVCS" en décrivant Git, mais en tant que programmeur relativement nouveau, cela ne veut rien dire pour moi. Je n'ai jamais vu un CVCS, et je n'ai jamais non plus travaillé avec un dépôt central distant lorsque je collabore avec d'autres (i.e. Github), donc jusqu'à présent je n'avais pas encore compris ce qui faisait la particularité de Git.
Alors, pourquoi n'est-ce pas une bonne idée d'utiliser git-fetch avec un job cron ? Garder toujours une copie du fichier distant avec lequel on travaille sur sa 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 mon remote dans les dernières 24 heures et de le lier à un hook udev pour la connexion internet.
Un cas d'utilisation de git fetch est que ce qui suit vous indiquera tout changement dans la branche distante depuis votre dernière extraction... ainsi vous pouvez vérifier avant d'effectuer une extraction réelle, qui pourrait changer des fichiers dans votre branche actuelle et votre copie de travail.
git fetch
git diff ...originVoir : https://git-scm.com/docs/git-diff concernant la syntaxe des points doubles et triples dans la commande diff
@Compustretch Il ne devait pas y avoir d'espace. git diff ...origin est équivalent à git diff $(git-merge-base HEAD origin) origin (voir le 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 ...origin est conceptuellement les changements apportés à origin puisque la branche actuelle a été ramifiée à partir de origin , tandis que git diff origin inclut également l'inverse des changements effectués dans la branche courante puisqu'elle a été ramifiée à partir de origin .
Il m'a fallu un peu de temps pour comprendre la différence, mais l'explication est simple. master dans votre serveur local est une branche.
Lorsque vous clonez un dépôt, vous récupérez l'intégralité du dépôt sur votre hôte local. Cela signifie qu'à ce moment-là, vous avez un pointeur origine/maître sur HEAD et le maître pointant vers le même HEAD .
lorsque vous commencez à travailler et à faire des commits, vous avancez le pointeur du maître à HEAD + vos engagements. Mais le pointeur origine/maître pointe toujours vers ce qu'il était lorsque vous avez cloné.
La différence sera donc la suivante :
git fetch il récupérera simplement tous les changements dans le référentiel distant ( GitHub ) et déplacer le pointeur d'origine/maître sur HEAD . Pendant ce temps, le master de votre branche locale continuera à pointer vers l'endroit où il se trouve.git pull il effectuera une recherche de base (comme expliqué précédemment) et fusionnera tous les nouveaux changements vers votre branche principale et déplacera le pointeur vers HEAD .
Origin/master est une branche locale qui est une COPIE de master sur origin. Lorsque vous récupérez des données, vous mettez à jour local:/origin/master. Une fois que l'on a compris que tout dans git est une branche, cela a beaucoup de sens et c'est un moyen très puissant de maintenir différents jeux de modifications, de faire des branches locales rapides, de fusionner et de rebaser, et en général d'obtenir beaucoup de valeur du modèle de branchement bon marché.
Toujours aussi confus. Je pensais que git fetch était de télécharger littéralement les changements sur le repo distant dans votre repo local, mais de ne PAS les valider - c'est-à-dire qu'ils doivent encore être ajoutés/validés dans votre repo local.
Fetch ne tire que depuis remote/origin (github) vers votre origine locale. Mais il ne les fusionne pas avec vos fichiers de travail actuels. Si vous faites un pull, il récupérera et fusionnera avec vos fichiers de travail actuels.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
392 votes
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
59 votes
Notre approche alternative est devenue
git fetch; git reset --hard origin/masterdans le cadre de notre flux de travail. Il efface les modifications locales, vous maintient à jour avec le master MAIS veille à ce que vous n'introduisiez pas de nouvelles modifications par-dessus les modifications actuelles et que vous ne fassiez pas n'importe quoi. Nous l'utilisons depuis un certain temps et il nous semble beaucoup plus sûr en pratique. Assurez-vous simplement d'ajouter/commiter/stocker tout travail en cours d'abord !32 votes
Assurez-vous de savoir comment utiliser correctement git stash. Si vous posez des questions sur 'pull' et 'fetch', alors peut-être que 'stash' a aussi besoin d'être expliqué...
43 votes
Beaucoup de personnes venant de Mercurial utilisent "git pull", pensant qu'il s'agit d'un équivalent de "hg pull". Ce qui n'est pas le cas. L'équivalent de "hg pull" dans Git est "git fetch".
12 votes
La commande git fetch récupère le code mis à jour avec la branche et récupère également les branches nouvellement ajoutées dans votre local, la commande git pull récupère uniquement le code mis à jour de la branche actuelle