J'ai du mal à comprendre git-fetch

Question

J'ai du mal à comprendre les nuances de git-fetch. Je comprends que faire un fetch récupère les références distantes dans une branche locale de suivi.

J'ai cependant quelques questions :

1. Est-il possible qu'une branche locale de suivi n'existe pas ? Si c'est le cas, sera-t-elle alors créée automatiquement ?

2. Que se passera-t-il si je fais un fetch et spécifier une branche de non suivi comme destination ?

3. La page de manuel de git-fetch le précise :

   git-fetch <options> <repository> <refspec>

Comment utiliser la refspec pour récupérer le contenu de mon master distant dans sa branche de suivi distante ? Je pense que cela peut être possible si mon HEAD actuel est sur master et que j'exécute

git fetch origin master

Cependant, puis-je utiliser le <+?src:dest> refspec pour obtenir la même chose ? Je pense que cela m'aidera à mieux comprendre les concepts.

Et une dernière question :

Mon fichier .git/config contient la ligne suivante pour la récupération (qui ne montre que les lignes pertinentes) :

fetch = +refs/heads/*:refs/remotes/origin/*

Quelqu'un peut-il expliquer ce que signifie exactement cette ligne ?

Answer 1

Premièrement, il n'y a pas de tel concept de suivi local les branches, seulement suivi à distance branches. Donc origine/maître est une branche de suivi à distance pour maître dans le origine repo.

En général, vous faites git fetch $remote qui met à jour toutes vos branches de suivi à distance, et en crée de nouvelles si nécessaire.

Cependant, vous pouvez aussi spécifier une refspec, mais cela ne touchera pas vos branches de suivi à distance, au lieu de cela, il ira chercher la branche que vous avez spécifiée et l'enregistrera dans FETCH_HEAD, à moins que vous ne spécifiez une destination. En général, vous ne voulez pas vous embêter avec ça.

Enfin,

fetch = +refs/heads/*:refs/remotes/origin/*

Cela signifie que si vous faites

git fetch origin

Il le fera effectivement :

git fetch origin +refs/heads/*:refs/remotes/origin/*

Ce qui signifie qu'une télécommande tête/foobar sera local remotes/origin/foobar et le signe plus signifie qu'ils seront mis à jour même s'ils ne sont pas en avance rapide.

Peut-être que ce que vous considérez comme une branche de suivi est quelque chose de lié à git pull et la configuration de la fusion.

Answer 2

felipec ont a répondu à la plupart des points de la question dans sa réponse .

Il en reste quelques uns (la plupart provenant de Récupérer git qui date un peu, malheureusement, à certains endroits) :

• Si Branche de suivi à distance (branche qui suit une branche dans un dépôt distant) n'existe pas, elle sera créée.

• La branche dans laquelle vous récupérez les données (la <dst> en [+]<src>:<dst> ) ne doit pas nécessairement résider dans remotes/<remote>/ espace de noms. Par exemple pour les dépôts en miroir ( git clone --mirror ) refspec est de 1 à 1. Dans les temps anciens, avant la mise en place de remotes séparées (avant remotes/<remote>/ espace de noms pour les refs de suivi à distance) maître a été récupéré dans la branche appelée origine . Même actuellement, les tags sont récupérés directement dans tags/ en miroir.

• Si la branche dans laquelle vous allez chercher les données (la partie droite de refspec <src>:<dst> existe, Git vérifiera si le téléchargement entraîne une avance rapide, c'est-à-dire si l'état actuel dans le fichier <dst> est l'ancêtre de l'État dans <src> dans un référentiel distant donné. Si ce n'est pas le cas, et que vous n'utilisez pas la commande -f / --force à git-fetch, ou préfixez refspec avec '+' (utilisez l'option +<src>:<dst> refspec) fetch refuserait de mettre à jour cette branche.

• git fetch origin master est équivalent à git fetch origin master: et non à git fetch origin master:master ; il stocke la valeur recherchée de maître branche (de l'éloignement origine ) en FETCH_HEAD et non dans maître la branche ou le suivi à distance remotes/origin/master branche. Il peut être suivi par git merge FETCH_HEAD . Généralement pas utilisé directement, mais dans le cadre d'un tirage unique sans définir de branche de suivi à distance : git pull <URL> <branch> .

• +refs/heads/*:refs/remotes/origin/* comme valeur pour récupération de l'origine à distance signifie que chaque branche (ref dans refs/heads/ ) dans les espaces de noms distants origine est récupéré dans la branche de suivi à distance nommée respectivement dans refs/remotes/origin/ l'espace de nom, par exemple maître branche dans origine (c'est-à-dire refs/heads/master ) serait récupéré dans origine/maître branche de suivi à distance (c.-à-d. refs/remotes/origin/master réf). Le préfixe '+' signifie que la récupération réussit même dans le cas où l'avance n'est pas rapide, c'est-à-dire lorsque la branche sur le distant est rebasée, ou rembobinée (remise à un état antérieur) ou modifiée d'une autre manière.

Sidenote : Vous voudrez probablement utiliser un niveau plus élevé git distant pour gérer les dépôts à distance et obtenir des mises à jour.

Answer 3

Notez que le principal mainteneur de Git a maintenant (Git 2.1, août 2014) ajouté cette explication pour les éléments suivants git fetch :
(Voir commettre fcb14b0 par Junio C Hamano ( gitster ) :

BRANCHES CONFIGURÉES POUR LE SUIVI À DISTANCE

Vous interagissez souvent avec le même référentiel distant en allant régulièrement et de manière répétée y chercher des données. Afin de suivre la progression d'un tel référentiel distant, git fetch vous permet de configurer remote.<repository>.fetch les variables de configuration.

Typiquement, une telle variable peut ressembler à ceci :

[remote "origin"]
fetch = +refs/heads/*:refs/remotes/origin/*

Cette configuration est utilisée de deux façons :

• Quand git fetch est exécuté sans spécifier les branches et/ou les balises à récupérer sur la ligne de commande, par ex. git fetch origin o git fetch , remote.<repository>.fetch sont utilisées comme valeurs de refspecs--ils spécifient les références à récupérer et les références locales à mettre à jour. .
  L'exemple ci-dessus récupérera toutes les branches qui existent dans le fichier origin (c'est-à-dire toute réf qui correspond au côté gauche de la valeur, refs/heads/* ) et de mettre à jour les branches de suivi à distance correspondantes dans le fichier refs/remotes/origin/* hiérarchie.

• Quand git fetch est exécuté avec des branches et/ou des balises explicites à récupérer sur la ligne de commande, par exemple git fetch origin master le <refspec> donnés sur la ligne de commande déterminent ce qui doit être récupéré (par ex. master dans l'exemple, qui est une abréviation de master: ce qui signifie que l'on doit aller chercher le ' master mais je ne dis pas explicitement quelle branche de suivi à distance mettre à jour avec elle à partir de la ligne de commande"), et la commande d'exemple récupérera seulement le master branche.
  Le site remote.<repository>.fetch déterminent quelle branche de suivi à distance, le cas échéant, est mise à jour.
  Lorsqu'il est utilisé de cette manière, le remote.<repository>.fetch n'ont pas d'effet sur la décision ce que est récupérée (c'est-à-dire que les valeurs ne sont pas utilisées comme refspecs lorsque la ligne de commande liste les refspecs) ; elles ne sont utilisées que pour décider de l'utilisation de la fonction où les références qui sont récupérées sont stockées en agissant comme un mappage.

Answer 4

Notez également que, avec Git 2.5+ (Q2 2015), git merge FETCH_HEAD peut fusionner plusieurs récupérations git .

Ver commettre d45366e par Junio C Hamano ( gitster ) , 26 mars 2015.
(fusionné par Junio C Hamano -- gitster -- en commettre bcd1ecd , 19 mai 2015)

" git merge FETCH_HEAD "a appris que le précédent " git fetch "pourrait être de créer une fusion Octopus, c'est-à-dire d'enregistrer plusieurs branches qui ne sont pas marquées comme "not-for-merge" ;
cela nous permet de perdre une invocation de style ancien " git merge <msg> HEAD $commits... " dans la mise en œuvre de " git pull " script ; la syntaxe de l'ancien style peut maintenant être dépréciée.

El git merge doc mentionner maintenant :

Quand FETCH_HEAD (et aucun autre commit) est spécifié, les branches enregistrées dans le .git/FETCH_HEAD par l'invocation précédente de git fetch pour la fusion sont fusionnées à la branche courante .

---

Git 2.13 (Q2 2017) retire officiellement l'ancienne syntaxe de git merge .
Voir commettre b439165 (26 mars 2015) par Junio C Hamano ( gitster ) .
(fusionné par Junio C Hamano -- gitster -- en commettre 1fdbfc4 , 30 mars 2017)

merge : drop ' git merge <message> HEAD <commit> La syntaxe

Arrêtez de soutenir " git merge <message> HEAD <commit> syntaxe " qui a est dépréciée depuis octobre 2007, et émet un message d'avertissement de dépréciation depuis la version 2.5.0.

Cela signifie que le message d'avertissement de style ancien " 'git merge <msg> HEAD <commit>' is deprecated. " n'est plus.