Phenquestions
O que são tags Git?
Tags Git são ponteiros para certos commits. Eles são como favoritos. Você pode usar qualquer tipo de convenção que deseja para criar tags. Mas a maioria das equipes de desenvolvimento usa números de versão como v1.0.1 ou v.1.1-a1 para criar tags.
Criação de tags
Existem dois tipos de tags no Git:
- Tags leves
- Tags anotadas
Tags leves
As tags leves são fáceis de criar. Você pode simplesmente usar a seguinte linha de comando:
tag $ gitEssas tags são armazenadas no .pasta git do seu repositório de trabalho.
Vamos criar algumas tags Git leves:
tag $ git v1.0.1$ git tag Release-20190401
No primeiro caso, criamos uma tag com “v1.0.1 ”. No segundo caso, criamos uma tag com “Release-20190401”. As tags leves não retornam nenhum valor. Além disso, é importante apontar que, como essas duas tags foram feitas uma após a outra, elas estão apontando para o mesmo commit.
Tags anotadas
As tags anotadas permitem que você armazene mais informações. Você pode usar a opção “-a” para criar essas tags:
$ git tag -aVamos tentar criar uma tag anotada:
git tag -a v1.0.2Uma janela pop-up será exibida para você inserir um comentário que deve ser semelhante a este:
## Escreva uma mensagem para a tag:
# V1.0.2
# Linhas começando com '#' serão ignoradas.
Insira um comentário e salve-o. Então, agora sua tag v1.0.2 é salvo com um comentário. Como alternativa, você pode inserir o comentário diretamente na linha de comando desta forma:
git tag -a v1.0.3 -m "Minha versão 1.0.3 "Localizando tags em seu código
Agora que criamos algumas tags, vamos ver o que temos:
$ git tag -lRelease-20190401
v1.0.1
v1.0.2
v1.0.3
Podemos ver que todas as nossas tags são exibidas em ordem alfabética. Você pode obter mais informações sobre as tags usando o “-n
Release-20190401 README atualizado.md
v1.0.1 README atualizado.md
v1.0.2 Minha versão 1.0.2
v1.0.3 Minha versão 1.0.3
Aqui você pode notar uma diferença entre tags leves e anotadas. Neste exemplo, “Release-20190401” e “v1.0.1 ”são tags leves. O “v1.0.2 ”e“ v1.0.3 ”são tags anotadas. Todos eles estão apontando para o mesmo commit (commit 34671):
$ git logcommit 106e0bb02a58ec3e818e9acdf3bb19a9247a0e84 (HEAD -> mestre, tag: v1.0.4)
Autor: Zak H
Data: Sáb 6 de abril 21:06:02 2019 -0700
Adicionado Recurso 2
commit 161c6e564e79624623ed767397a98105426d0ec4
Autor: Zak H
Data: Sáb 6 de abril 21:05:25 2019 -0700
Adicionado Recurso 1
commit 34671d824f9b9951e57f867998cb3c02a11c4805 (tag: v1.0.3, tag: v1.0.2,
tag: v1.0.1, tag: Release-20190401)
Autor: Zak H
Data: Sáb 6 de abril 20:24:53 2019 -0700
README atualizado.md
commit afe9b0c7c9fbce3c3d585afe67358a5eec226e2c (origem / mestre)
Autor: Zak H
Data: Sáb 6 de abril 20:23:55 2019 -0700
Iniciar
No entanto, as tags leves estão mostrando os comentários do próprio commit que é “README atualizado.md ”, enquanto as tags anotadas mostram os comentários individuais que foram adicionados a elas durante o processo de criação da tag.
Dica: Se quiser encontrar o número de commit de uma tag específica, você pode usar o comando “git show”:
$ git show v1.0.3tag v1.0.3
Tagger: Zak H
Data: Sáb 6 de abril 20:43:30 2019 -0700
Minha versão 1.0.3
commit 34671d824f9b9951e57f867998cb3c02a11c4805 (tag: v1.0.3, tag: v1.0.2, tag:
v1.0.1, tag: Release-20190401)
Autor: Zak H
Data: Sáb 6 de abril 20:24:53 2019 -0700
README atualizado.md
diff --git a / README.md b / README.md
índice 9daeafb… 180cf83 100644
--- a / README.md
+++ b / README.md
@@ -1 +1 @@
-teste
+test2
Marcando commits mais antigos
Você também pode voltar e marcar um commit mais antigo. Vejamos os registros:
$ git log --oneline106e0bb (HEAD -> mestre, tag: v1.0.4) Recurso 2 adicionado
161c6e5 Adicionado Recurso 1
34671d8 (tag: v1.0.3, tag: v1.0.2, tag: v1.0.1, tag: Release-20190401) README atualizado.md
afe9b0c (origem / mestre) Init
$
Notamos que o commit 161c6e5 não tem uma tag associada. Podemos marcar este commit assim:
$ git tag -a Release-20190402 161c6e5Irá abrir a janela de comentários. Depois de colocar o comentário, podemos ver que temos o commit marcado agora:
$ git tag -n1Release-20190401 README atualizado.md
Release-20190402 Tag adicionada a um commit mais antigo
v1.0.1 README atualizado.md
v1.0.2 Minha versão 1.0.2
v1.0.3 Minha versão 1.0.3
v1.0.4 Recurso 2 adicionado
Removendo Tags
Suponha que você decida que não quer as tags “Release-“, pois são confusas. Você pode primeiro encontrar todas as tags “Release-“:
$ git tag -l Release *Release-20190401
Release-20190402
Agora, você pode removê-los com a opção “-d”:
$ git tag -d Release-20190401Tag excluída 'Release-20190401' (era 34671d8)
$ git tag -d Release-20190402
Tag excluída 'Release-20190402' (era 6ee37bc)
Se verificarmos as tags novamente, devemos ver apenas as tags que começam com “v”:
$ git tag -n1v1.0.1 README atualizado.md
v1.0.2 Minha versão 1.0.2
v1.0.3 Minha versão 1.0.3
v1.0.4 Recurso 2 adicionado
Sobrescrevendo Tags
Suponha que tenhamos uma situação onde “v1.0.A etiqueta de 4 ”está apontando para o Recurso 2:
$ git log --onelined7b18a4 (HEAD -> master) Recurso adicionado 3
106e0bb (tag: v1.0.4) Recurso 2 adicionado
161c6e5 Adicionado Recurso 1
34671d8 (tag: v1.0.3, tag: v1.0.2, tag: v1.0.1) README atualizado.md
afe9b0c (origem / mestre) Init
Mas queremos a tag “v1.0.4 "para apontar para o Recurso 3. Se tentarmos retagá-lo, obteremos este erro:
tag $ git v1.0.4 d7b18a4fatal: tag 'v1.0.4 'já existe
Podemos superar esse problema com a opção “-f”:
$ git tag -f v1.0.4 d7b18a4Tag 'v1 atualizada.0.4 '(era 106e0bb)
Se verificarmos o log novamente, vemos que a tag mudou para o commit que desejamos:
$ git log --onelined7b18a4 (HEAD -> mestre, tag: v1.0.4) Recurso adicionado 3
106e0bb Adicionado recurso 2
161c6e5 Adicionado Recurso 1
34671d8 (tag: v1.0.3, tag: v1.0.2, tag: v1.0.1) README atualizado.md
afe9b0c (origem / mestre) Init
Alternativamente, você também pode excluir uma tag e adicioná-la novamente a um novo commit.
Compartilhando tags com outros usuários
Quando você envia seu código para o repositório remoto, as tags Git não são enviadas automaticamente. Se você deseja compartilhar suas tags com outros usuários, deve enviá-las exclusivamente.
As tags podem ser enviadas assim:
$ git push origin v1.0.4Contando objetos: 12, concluído.
Compressão delta usando até 4 threads.
Comprimir objetos: 100% (4/4), concluído.
Escrevendo objetos: 100% (12/12), 902 bytes | 150.00 KiB / s, pronto.
Total 12 (delta 0), reutilizado 0 (delta 0)
Para / Users / zakh / _work / LearnGIT / git_tagging / remote / project_mayhem
* [nova tag] v1.0.4 -> v1.0.4
Agora, se outros usuários clonarem o repositório remoto, eles verão apenas a tag que foi enviada (“v1.0.4 ”neste caso).
Usando Ramificações versus Tags
Ramificações são úteis para novos recursos ou experiências. Geralmente, você deseja ramificar quando houver trabalho futuro que precise ser feito e o trabalho atrapalhar seu desenvolvimento atual. Por outro lado, as tags são mais úteis como instantâneos. Você deve usá-los para lembrar coisas específicas que você já fez.
Em conclusão
A tag Git é um recurso subutilizado que pode fornecer uma ótima maneira de acompanhar os lançamentos e recursos especiais. Se você configurar boas práticas em torno de tags, isso pode ajudá-lo a se comunicar facilmente com sua equipe de desenvolvimento e simplificar seus processos de desenvolvimento.
Um estudo mais aprofundado:
- https: // git-scm.com / book / en / v2 / Git-Basics-Tagging
- https: // softwareengineering.stackexchange.com / questions / 165725 / git-branching-and-tagging-best-Practices
- https: // www.atlassiano.com / git / tutorials / inspecting-a-repository / git-tag
- https: // en.wikipedia.org / wiki / Software_versioning
- https: // www.techopedia.com / definição / 25977 / versão de software
