Como obter a marca git remota
Quando verificar a marca git remota use um comando como este:
git checkout -b local_branch_name origin/remote_tag_name
error: pathspec `origin/remote_tag_name` did not match any file(s) known to git.
consigo encontrar o remote_tag_name Quando USO o comando git tag.
2 answers
Vamos começar por explicar o que é uma etiqueta no git
Uma marca é usada para rotular e marcar um compromisso específico na história.
É geralmente usado para marcar pontos de lançamento (por exemplo. v1.0, etc.).Embora uma marca possa parecer semelhante ao branch, uma marca, no entanto, não muda.
Ele aponta diretamente para um commit específico na história.
Vais conseguir. não ser capaz de obter as marcas se não for localmente no seu repositório então primeiro, você tem que fetch as marcas para o seu repositório local.
Primeiro, certifique-se de que a etiqueta existe localmente, fazendo
# --all will fetch all the remotes.
# --tags will fetch all tags as well
git fetch --all --tags --prune
Em seguida, verifique a etiqueta, executando
git checkout tags/<tag_name> -b <branch_name>
Em vez de origin usa o prefixo tags/.
Nesta amostra, tem 2 Marcas na versão 1. 0 e na versão 1. 1. pode obtê-las com qualquer uma das seguintes:
git checkout A ...
git checkout version 1.0 ...
git checkout tags/version 1.0 ...
Todo o o acima fará o mesmo, uma vez que tag é apenas um ponteiro para um determinado commit.
origem: https://backlog.com/git-tutorial/img/post/stepup/capture_stepup4_1_1.png
Como ver a lista de todas as etiquetas?
# list all tags
git tag
# list all tags with given pattern ex: v-
git tag --list 'v-*'
Como criar etiquetas?
Existem 2 maneiras de criar uma etiqueta:
# normal tag
git tag
# annotated tag
git tag -a
A diferença entre o 2 é que ao criar uma marca anotada você pode adicionar metadados como você tem num git compromisso:
nome, e-mail, data, comentário e assinatura
# delete any given tag
git tag -d <tag name>
# Don't forget to remove the deleted tag form the server with push tags
Para obter o ocntent de uma dada marca, pode usar o comando checkout.
Como foi explicado, as marcas abover são como qualquer outro commits para que possamos usar checkout e em vez de usar o SHA-1, basta substituí-lo pelo tag_ name
Opção 1:
# Update the local gir repo with the latest tags from all remotes
git fetch --all
# checkout the specific tag
git checkout tags/<tag> -b <branch>
Opção 2:
Usando o comando clone
Desde o suporte do git O clone do shalow adicionando o --branch ao comando do clone, podemos usar o nome da marca em vez do nome do ramo. O Git sabe "traduzir" o SHA-1 dado para o commit relevante
# Clone a specific tag name
git clone <url. --branch=<tag_name>
Git clone -- branch=
--branchtambém pode pegar tags e destacar a cabeça no commit no repositório resultante.
(esta resposta levou algum tempo a escrever, e a resposta de codeWizard está correcta em termos de Objectivo e essência, mas não completamente completa, por isso vou postar isto na mesma.)
Não existe tal coisa como uma"etiqueta de Git remota". Só há "etiquetas". Digo tudo isso para não ser pedante,1 mas porque há uma grande confusão sobre isso com casual Git usuários, e o Git documentação não é muito útil2 para iniciantes. (Não é claro se o a confusão vem por causa da documentação pobre, ou a documentação pobre vem porque isso é inerentemente um pouco confuso, ou o que.)
Existem "balcões remotos", mais propriamente chamados de" balcões de rastreamento remoto", mas vale a pena notar que estes são na verdade entidades locais. Porém, não há tags remotos, a menos que os inventes. Existem apenas tags locais, então você precisa obter a tag localmente, a fim de usá-lo.
O formulário geral para os nomes commits específicos-que o Git chama de referências - é qualquer cadeia que começa por refs/. Um texto que começa por refs/heads/ nomeia um ramo; um texto que começa por refs/remotes/ nomeia um ramo de seguimento remoto; e um texto que começa por refs/tags/ nomeia uma marca. O nome refs/stash é a referência do stash (como usado por git stash; repare na falta de uma barra final).
refs/: HEAD, ORIG_HEAD, MERGE_HEAD, e CHERRY_PICK_HEAD em particular, todos também são nomes isto pode referir-se a commits específicos (embora HEAD normalmente contenha o nome de um ramo, isto é, contenha ref: refs/heads/branch). Mas em geral, as referências começam por refs/.
Uma coisa que o Git faz para tornar isto confuso é que lhe permite omitir o {[[2]}, e muitas vezes a palavra depois de refs/. Por exemplo, você pode omitir refs/heads/ ou refs/tags/ quando se refere a um ramo ou etiqueta local-e na verdade você deve omitir refs/heads/ ao verificar um ramo local! Você pode fazer isso sempre que o resultado é unívoco, ou - como acabamos de notar-quando você deve fazê-lo (para git checkout branch).
É verdade que as referências existem não só no seu próprio repositório, mas também em repositórios remotos. No entanto, o Git dá-lhe acesso às referências de um repositório remoto apenas em momentos muito específicos: nomeadamente, durante as operações fetch e push. Você também pode usar git ls-remote ou git remote show para vê-los, mas fetch e push são os pontos de contacto mais interessantes.
Repspects
Durante fetch e push, O Git usa strings que chama de refspects para transferir referências entre o repositório local e remoto. Assim, é neste momento, e através de repspects, que dois repositórios Git podem entrar em sincronia uns com os outros. Uma vez que seus nomes estão em sincronia, você pode usar o mesmo nome que alguém com o remoto usa. No entanto, há alguma magia especial aqui em fetch, e afecta tanto os nomes dos ramos como os nomes das marcas.
Você deve pensar em {[31] } Como dirigir o seu Git para chamar (ou talvez texto-mensagem) outro Git - o "remoto" - e ter uma conversa com ele. No início desta conversa, o remoto lista todas as suas referências: tudo em refs/heads/ e tudo em refs/tags/, juntamente com quaisquer outras referências que tenha. O seu Git verifica através destes e (com base no habitual fetch refspec) renomeia os seus ramos.
origin:
$ git config --get-all remote.origin.fetch
+refs/heads/*:refs/remotes/origin/*
$
Este refspec instrui o seu Git a tomar todos os nomes correspondentes refs/heads/* - isto é, cada ramo no remoto-e mudar o seu nome para refs/remotes/origin/*, isto é, manter a parte correspondente na mesma, mudando o nome do ramo (refs/heads/) para um nome de ramo de rastreamento remoto (refs/remotes/, especificamente, refs/remotes/origin/).
É através deste refspec que os ramosorigin se tornam os ramos de localização remota para controlo remoto origin. O nome do ramo torna-se nome do ramo de rastreamento remoto, com o nome do remoto, neste caso origin, incluído. O sinal mais + na frente do refspec define a bandeira "force", ou seja, o seu ramo de rastreamento remoto será atualizado para corresponder ao nome do ramo remoto, independentemente do que for preciso para que ele corresponda. (Sem o +, as atualizações de branch são limitadas a mudanças de" fast forward", e as atualizações de tag são simplesmente ignoradas desde a versão 1.8.2 do Git-antes de então as mesmas regras de fast-forward aplicadas.)
Marcas
Mas e as etiquetas? Não há refspec para eles-pelo menos, não por padrão. Você pode definir um, em que caso a forma de o refspec é contigo; ou podes corrergit fetch --tags. Usando --tags tem o efeito de adicionar refs/tags/*:refs/tags/* para o refspec, por exemplo, ele traz mais de todas as marcas (--tags forçosamente atualizações de suas etiquetas a partir do controle remoto marcas, como se o refspec leitura +refs/tags/*:refs/tags/*; esta pode ser uma diferença no comportamento de uma versão anterior of Git).
Observe que não há nenhuma renomear aqui: se remote origin tem tag xyzzy, e você não, e você git fetch origin "refs/tags/*:refs/tags/*", obtém refs/tags/xyzzy adicionado ao seu repositório (apontando para o mesmo consolidar como no controle remoto). Se utilizar +refs/tags/*:refs/tags/* , a sua etiqueta xyzzy, se tiver uma, é substituída pela de origin. Isto é, a bandeira de força + em um refspec significa "substituir o valor de minha referência pelo que meu Git recebe de seu Git".
Marcas automáticas durante busca
Por razões históricas,3 se não utilizar a opção--tags nem a opção --no-tags, git fetch toma medidas especiais. Lembre-se que dissemos acima que o remoto começa por mostrar ao seu Git local todas das suas referências, quer o seu Git local queira vê-las ou não.4 o seu Git toma nota de todas as etiquetas que vê neste momento. Editar, Janeiro de 2017: teste mostra que o comportamento no Git 2.10 agora é: Se a sua Git oferece uma tag chamada T, e você não tem uma etiqueta com o nome T, e a cometer ID associado a T é um antepassado de um dos seus ramos que o seu git fetch está a analisar, o Git adiciona to your tags with or without --tags. A adição de --tags faz com que o seu Git obtenha todas as as suas etiquetas, e também force update.
Conclusão
Pode ter de usar git fetch --tags para obter as suas etiquetas. Se os seus nomes de marcas entrarem em conflito com os seus nomes de marcas existentes, você pode (dependendo da versão do Git) ter mesmo de apagar (ou mudar o nome) algumas das suas marcas, e depois executar git fetch --tags, para obter as suas marcas. Dado que as marcas-ao contrário dos ramos remotos-não têm um nome automático, os seus nomes de marcas devem corresponder aos seus nomes de marcas, razão pela qual pode ter problemas com conflitos.
Em a maioria dos casos normais, no entanto, um simples git fetch fará o trabalho, trazendo seus commits e suas tags correspondentes, e uma vez que eles-quem quer que sejam-Irão tag commits no momento em que publicarem esses commits, você vai manter-se com suas tags. Se você não fizer suas próprias tags, nem misturar seu repositório e outros repositórios (através de vários comandos), você não terá nenhum nome de tag colisões também, assim você não terá que se preocupar com a exclusão ou renomear tags, a fim de obter as suas tags.
Quando precisar de nomes qualificados
Eu mencionei acima que você pode omitir {[[2]} quase sempre, e refs/heads/ e refs/tags/ e assim por diante na maioria das vezes. Mas quando não podes?
A resposta completa (ou quase completa de qualquer forma) está em a documentaçãogitrevisions. O Git irá resolver um nome para um ID de commit usando a sequência de seis passos dada no link. Curiosamente, as marcas sobrepõem-se às ramificações: se houver uma marca xyzzy e uma ramificação xyzzy, e elas apontam para commits diferentes, então:
git rev-parse xyzzy
Dar-lhe-á o ID para o qual a marca aponta. No entanto-e isto é o que falta gitrevisions-git checkout prefere nomes de ramos, então git checkout xyzzy irá colocá-lo no ramo, desconsiderando a etiqueta.
Em caso de ambiguidade, quase sempre se pode soletrar o nome do árbitro usando o seu nome completo, refs/heads/xyzzy ou refs/tags/xyzzy. (Note que este funciona com git checkout, mas de uma forma talvez inesperada: git checkout refs/heads/xyzzy causa uma saída de cabeça separada em vez de uma saída de ramo. É por isso que você só tem que notar que git checkout irá usar o nome curto como primeiro nome de um ramo: é assim que você verifica o ramo xyzzy mesmo que a marca xyzzy exista. Se quiser verificar a etiqueta, pode utilizar refs/tags/xyzzy.)
Porque (como gitrevisions notas) o Git vai tentar refs/name, Você também pode simplesmente escrever tags/xyzzy para identificar o commit marcado xyzzy. (Se alguém conseguiu escreva uma referência válida chamada xyzzy em $GIT_DIR, no entanto, isto irá resolver como $GIT_DIR/xyzzy. Mas normalmente apenas os vários nomes *HEAD devem estar em $GIT_DIR.)
1está bem, está bem, "não só para ser pedante". :-)
2alguns diriam "muito pouco útil", e eu tenderia a concordar, na verdade.
3basicamente, git fetch, e todo o conceito de comandos e repspectos, foi um pouco uma adição tardia ao Git, acontecendo em torno do hora do Git 1.5. Antes disso, havia apenas alguns casos especiais ad-hoc, e o rastreamento de etiquetas era um deles, então ele foi superado através de código especial.
4se ajudar, pense no Git remoto como um flasher , no significado de Gíria.