Ho usato fetch
seguito da checkout
...
git fetch <remote> <rbranch>:<lbranch>
git checkout <lbranch>
... dove si <rbranch>
trova il ramo remoto o riferimento sorgente ed <lbranch>
è il ramo locale ancora inesistente o riferimento destinazione che si desidera tracciare e che probabilmente si desidera denominare lo stesso ramo remoto o riferimento sorgente. Questo è spiegato sotto le opzioni nella spiegazione di <refspec>
.
Git è così intelligente che auto completa il primo comando se scheda dopo le prime lettere del ramo remoto. Cioè, non devo nemmeno nominare il ramo locale, Git copia automaticamente il nome del ramo remoto per me. Grazie Git!
Inoltre, come mostra la risposta in questo post Stack Overflow simile , se non fetch
assegni un nome al ramo locale , puoi comunque crearlo quando lo controlli usando il -b
flag. Cioè, git fetch <remote> <branch>
seguito da git checkout -b <branch> <remote>/<branch>
fa esattamente lo stesso della mia risposta iniziale. Ed evidentemente, se il repository ha un solo telecomando, allora si può solo fare git checkout <branch>
dopo fetch
e creerà una filiale locale per voi. Ad esempio, hai appena clonato un repository e vuoi controllare rami aggiuntivi dal telecomando.
Credo che parte della documentazione per fetch
potrebbe essere stata copiata alla lettera pull
. In particolare la sezione relativa <refspec>
a opzioni è lo stesso. Tuttavia, non credo che lo fetch
farà mai merge
, quindi se si lascia vuoto il lato di destinazione del colon, fetch
non si dovrebbe fare nulla .
NOTA: git fetch <remote> <refspec>
è l'abbreviazione per git fetch <remote> <refspec>:
cui quindi non farebbe nulla, ma git fetch <remote> <tag>
è lo stesso git fetch <remote> <tag>:<tag>
che dovrebbe copiare il telecomando <tag>
localmente.
Immagino che ciò sia utile solo se si desidera copiare un ramo remoto localmente, ma non è necessario verificarlo immediatamente. Altrimenti, ora userei la risposta accettata , che è spiegata in dettaglio nella prima sezione della descrizione del checkout e successivamente nella sezione delle opzioni sotto la spiegazione di --track
, dal momento che è una riga. Beh ... una specie di one-liner, perché dovresti comunque correre per git fetch <remote>
primo.
Cordiali saluti: L'ordine del <refspecs>
(fonte: destinazione) spiega il bizzarro metodo pre-Git 1.7 per cancellare i rami remoti . Cioè, non inserire nulla nel refspec di destinazione.