Différences entre les commandes “git pull” en tirant de l’origine?

Quelles sont les différences entre ces commandes?:

# 1 git pull # 2 git pull origin # 3 git pull origin master # 4 git pull origin/master # 5 git pull origin HEAD:master 

git pull est une commande de commodité qui fait différentes choses en même temps. Fondamentalement, il s’agit simplement d’une combinaison de git fetch , qui se connecte au référentiel distant et récupère les nouveaux commits, et git merge (ou git rebase ) qui incorpore les nouveaux commits dans votre twig locale. En raison des deux commandes différentes impliquées, le sens de git pull n’est pas toujours évident.

Vous pouvez configurer un stream amont pour une twig locale. Après un nouveau clone, vous aurez une twig locale “master”, une “origine” distante et votre twig master aura “origine / master” en amont. Je suppose cette configuration ci-dessous. (Vous pouvez voir votre configuration en amont avec git branch -vv ou en regardant .git / config.)

Maintenant pour vos questions:

  1. git pull = git fetch origin + git merge origin/master (ou quel que soit votre amont)
  2. git pull origin = git pull (tant que l’origine est votre télécommande en amont)
  3. git pull origin master = git fetch origin master + git merge FETCH_HEAD
  4. git pull origin/master : invalide sauf si vous avez une télécommande appelée “origine / maître”
  5. git pull origin HEAD:master : essaye de réinitialiser directement votre maître local sur les points HEAD sur origine. (Ne fais pas ça.)

Un pull est fondamentalement un fetch (qui récupère des commits et des objects associés depuis un référentiel distant) puis une opération qui les “applique” dans votre copie de travail. La seconde étape est, par défaut, effectuée à l’aide d’une merge mais vous pouvez définir la variable pull.rebase sur true , puis la rebaser à la place.

Il y a deux questions qui apparaissent avec la commande pull . La première est: qu’est-ce qui va exactement chercher? Et la seconde est, comment applique-t-il ces modifications à ma copie de travail? Commençons par le premier. La forme complète de la commande est

 git pull [options] [repository] [...] 

Les options sont des indicateurs qui contrôlent le comportement (par exemple, –rebase pour que pull fonctionne comme un fetch + rebase même si pull.rebase est false ).

repository est le nom (ou l’URL) de la télécommande à récupérer.

refspecs sont un moyen succinct de spécifier les références de la télécommande que vous souhaitez récupérer et où vous voulez les placer dans votre copie de travail actuelle.

Prenons d’abord la forme la plus explicite.

  git pull origin branch1:branch2 

Cela dit, tirez les modifications dans la branch1 référence1 sur l’ origin appelée à distance, puis fusionnez-les (ou rebassez-les) dans la twig de la branch2 locale. Si, par exemple, je dis git pull origin master:dev , j’aurai une twig locale appelée dev qui dev le même commit que master . Les détails sur la façon de spécifier les refspecs sont ici . Vous pouvez utiliser un * pour indiquer plusieurs refspecs. Par exemple, git pull origin refs/heads/*:refs/heads/* extraira toutes les twigs (stockées sous des heads ) dans le référentiel local et les fusionnera dans des twigs locales portant les mêmes noms.

Maintenant, retirons les arguments un par un pour discuter de la façon dont le travail par défaut fonctionne. Tout d’abord, nous pouvons supprimer la destination de notre refspec et dire simplement git pull origin branch1 . Cela va d’abord fetch la twig distante branch1 dans votre référentiel local. Il sera disponible sous la forme d’une référence temporaire appelée FETCH_HEAD . Après cela, il lancera git merge FETCH_HEAD qui fusionnera cette twig dans votre twig active actuelle (c.-à-d. HEAD ). Cela se produit souvent lorsque vous vous trouvez dans une succursale locale et que vous souhaitez récupérer des modifications depuis une télécommande dans cette twig.

Maintenant, laissez tomber la branch1 complètement et dites simplement l’ git pull origin branch1 git pull origin . Maintenant, git sait où aller ( origin ) mais ne sait pas quoi chercher. Il a des défauts pour cela. Le scénario le plus courant est lorsque votre fichier de configuration a une option branch..merge (il s’agit d’une entrée appelée merge dans une section comme [branch "master"] ). Si c’est le cas, il utilisera les refspecs pour l’opération.

Si nous abandonnons complètement l’ origin et disons simplement git pull , cela vérifiera la configuration pour voir s’il y a une branch..remote qui spécifie la télécommande à partir de laquelle. Cela avec ce qui précède vous dit quoi tirer.

Vos points # 4 et # 5 ne sont pas des cas d’utilisation normaux. Le premier a du sens si vous avez une télécommande appelée origin/master qui est peu probable. origin/master est généralement une référence locale qui suit la twig master sur l’ origin distante. La seconde tentera de récupérer les modifications sur HEAD sur la télécommande (la twig par défaut qui est généralement master ), puis les fusionnera dans votre master local. Bien que cela puisse être quelque chose que vous voulez faire sur une base régulière, la commande est assez peu conventionnelle et pas quelque chose que j’ai vu souvent utilisé.

J’ai sauté quelques détails mais ceux-ci devraient suffire à vous garder en sécurité et à l’aise dans votre travail quotidien. Pour tous les détails, vous pouvez consulter la page de manuel pour git pull .