J'ai utilisé fetch
suivi de checkout
...
git fetch <remote> <rbranch>:<lbranch>
git checkout <lbranch>
... où <rbranch>
est la branche distante ou la référence source et <lbranch>
est la branche locale ou référence de destination encore inexistante que vous souhaitez suivre et que vous souhaitez probablement nommer de la même manière que la branche distante ou la référence source. Ceci est expliqué dans les options de l'explication de .<refspec>
Git est tellement intelligent qu'il termine automatiquement la première commande si je tabule après les premières lettres de la branche distante. Autrement dit, je n'ai même pas besoin de nommer la branche locale, Git copie automatiquement le nom de la branche distante pour moi. Merci Git!
De même, comme le montre la réponse de ce post similaire sur le débordement de pile , si vous ne nommez pas la branche locale fetch
, vous pouvez toujours la créer lorsque vous la retirez en utilisant l' -b
indicateur. Autrement dit, git fetch <remote> <branch>
suivi de git checkout -b <branch> <remote>/<branch>
fait exactement la même chose que ma réponse initiale. Et évidemment, si votre référentiel n'a qu'une seule télécommande, alors vous pouvez le faire git checkout <branch>
après fetch
et il créera une branche locale pour vous. Par exemple, vous venez de cloner un référentiel et souhaitez extraire des branches supplémentaires de la télécommande.
Je pense qu'une partie de la documentation de fetch
peut avoir été copiée textuellement pull
. En particulier , la section <refspec>
dans les options est le même. Cependant, je ne crois pas que cela fetch
arrivera jamais merge
, de sorte que si vous laissez le côté destination du côlon vide, fetch
ne faites rien .
REMARQUE: git fetch <remote> <refspec>
est un raccourci pour git fetch <remote> <refspec>:
lequel ne ferait donc rien, mais git fetch <remote> <tag>
est le même que celui git fetch <remote> <tag>:<tag>
qui doit copier la télécommande <tag>
localement.
Je suppose que cela n'est utile que si vous souhaitez copier une branche distante localement, mais pas nécessairement la vérifier immédiatement. Sinon, j'utiliserais maintenant la réponse acceptée , qui est expliquée en détail dans la première section de la description de la commande et plus tard dans la section des options sous l'explication de --track
, car il s'agit d'une ligne unique. Eh bien ... une sorte de monoplace, car il faudrait toujours courir en git fetch <remote>
premier.
FYI: L'ordre de la <refspecs>
(source: destination) explique la méthode bizarre pré Git 1.7 pour supprimer les branches distantes . Autrement dit, ne rien insérer dans la spécification de destination.