-
1. Começando
- 1.1 Sobre Controle de Versão
- 1.2 Uma Breve História do Git
- 1.3 O Básico do Git
- 1.4 A Linha de Comando
- 1.5 Instalando o Git
- 1.6 Configuração Inicial do Git
- 1.7 Pedindo Ajuda
- 1.8 Sumário
-
2. Fundamentos de Git
-
3. Branches no Git
-
4. Git on the Server
- 4.1 The Protocols
- 4.2 Getting Git on a Server
- 4.3 Generating Your SSH Public Key
- 4.4 Setting Up the Server
- 4.5 Git Daemon
- 4.6 Smart HTTP
- 4.7 GitWeb
- 4.8 GitLab
- 4.9 Third Party Hosted Options
- 4.10 Summary
-
5. Distributed Git
-
6. GitHub
- 6.1 Configurando uma conta
- 6.2 Contribuindo em um projeto
- 6.3 Maintaining a Project
- 6.4 Managing an organization
- 6.5 Scripting GitHub
- 6.6 Summary
-
7. Git Tools
- 7.1 Revision Selection
- 7.2 Interactive Staging
- 7.3 Stashing and Cleaning
- 7.4 Signing Your Work
- 7.5 Searching
- 7.6 Rewriting History
- 7.7 Reset Demystified
- 7.8 Advanced Merging
- 7.9 Rerere
- 7.10 Debugging with Git
- 7.11 Submodules
- 7.12 Bundling
- 7.13 Replace
- 7.14 Credential Storage
- 7.15 Summary
-
8. Customizing Git
- 8.1 Git Configuration
- 8.2 Git Attributes
- 8.3 Git Hooks
- 8.4 An Example Git-Enforced Policy
- 8.5 Summary
-
9. Git and Other Systems
- 9.1 Git as a Client
- 9.2 Migrating to Git
- 9.3 Summary
-
10. Funcionamento Interno do Git
- 10.1 Encanamento e Porcelana
- 10.2 Objetos do Git
- 10.3 Referências do Git
- 10.4 Packfiles
- 10.5 The Refspec
- 10.6 Transfer Protocols
- 10.7 Maintenance and Data Recovery
- 10.8 Variáveis de ambiente
- 10.9 Sumário
-
A1. Appendix A: Git em Outros Ambientes
- A1.1 Graphical Interfaces
- A1.2 Git in Visual Studio
- A1.3 Git in Eclipse
- A1.4 Git in Bash
- A1.5 Git in Zsh
- A1.6 Git in Powershell
- A1.7 Resumo
-
A2. Appendix B: Embedding Git in your Applications
- A2.1 Command-line Git
- A2.2 Libgit2
- A2.3 JGit
-
A3. Appendix C: Git Commands
- A3.1 Setup and Config
- A3.2 Getting and Creating Projects
- A3.3 Basic Snapshotting
- A3.4 Branching and Merging
- A3.5 Sharing and Updating Projects
- A3.6 Inspection and Comparison
- A3.7 Debugging
- A3.8 Patching
- A3.9 Email
- A3.10 External Systems
- A3.11 Administration
- A3.12 Plumbing Commands
2.6 Fundamentos de Git - Criando Tags
Criando Tags
Da mesma forma que a maioria dos VCSs, o Git tem a habilidade de marcar pontos específicos na história como sendo importantes. Normalmente as pessoas usam essa funcionalidade para marcar pontos onde foram feitas releases (v1.0 e assim por diante). Nessa sessão, você irá aprender como listar as tags existentes, como criar novas tags e quais são os diferentes tipos de tags.
Listando suas Tags
Listar tags disponíveis no Git não tem rodeios.
Apenas escreva git tag
:
$ git tag
v0.1
v1.3
Esse comando lista as tags em ordem alfabética; a ordem na qual eles aparecerem não tem real importância.
Você pode também procurar por tags com algum padrão em especifico. O repositório fonte do Git, por exemplo, contém mais de 500 tags. Se você deseja procurar apenas a série 1.8.5, você pode executar isso:
$ git tag -l "v1.8.5*"
v1.8.5
v1.8.5-rc0
v1.8.5-rc1
v1.8.5-rc2
v1.8.5-rc3
v1.8.5.1
v1.8.5.2
v1.8.5.3
v1.8.5.4
v1.8.5.5
Criando Tags
O Git usa dois tipos de tags: Leve e Anotada.
Uma tag do tipo leve é muito parecida com um branch que não muda – Ela apenas aponta para um commit em especifico.
Tags anotadas, entretanto, são um armazenamento completo de objetos no banco de dados do Git. Elas têm checksum, contem marcações de nome, email e data; têm uma mensagem de tag; e podem ser assinadas e asseguradas pela GPG (GNU Privacy Guard). É geralmente recomendado que você crie tags anotadas assim você tem todas as informações; mas se você quer um tag temporária ou por alguma razão não quer manter todas as informações, tags do tipo leve esta disponíveis para isso.
Tags Anotadas
Criar uma tag anotada no Git é simples.
A forma mais fácil é por especificar o parâmetro -a
quando você executa o comando tag
:
$ git tag -a v1.4 -m "my version 1.4"
$ git tag
v0.1
v1.3
v1.4
O -m
define a mensagem de tag, a qual é armazenada junto com a tag.
Se você não especificar uma mensagem para uma tag anotada, o Git abre seu editor para que você possa digitar nele.
Você pode ver os dados da tag juntamente com o commit onde ela foi realizada usando o comando git show
:
$ git show v1.4
tag v1.4
Tagger: Ben Straub <ben@straub.cc>
Date: Sat May 3 20:19:12 2014 -0700
my version 1.4
commit ca82a6dff817ec66f44342007202690a93763949
Author: Scott Chacon <schacon@gee-mail.com>
Date: Mon Mar 17 21:52:11 2008 -0700
changed the version number
Este mostra as informações de tag, a data do commit atrelado a tag, e a mensagem antes mesmo de mostrar as informações do commit.
Tags de Tipo Leve
Uma outra forma de submeter uma tag é usando o tipo leve.
Isso é basicamente o checksum de commit armazenando em um arquivo – nenhuma outra informação é mantida.
Para criar uma tag do tipo leve, não forneça as opções -a
, -s
, or -m
:
$ git tag v1.4-lw
$ git tag
v0.1
v1.3
v1.4
v1.4-lw
v1.5
Dessa vez, se você executar git show
nessa tag, você não verá as informações extras.
O comando apenas mostrará o commit:
$ git show v1.4-lw
commit ca82a6dff817ec66f44342007202690a93763949
Author: Scott Chacon <schacon@gee-mail.com>
Date: Mon Mar 17 21:52:11 2008 -0700
changed the version number
Criando Tags posteriormente
Você pode também criar uma tag após já ter realizado o commit. Suponha que seu histórico de commits seja semelhante a este:
$ git log --pretty=oneline
15027957951b64cf874c3557a0f3547bd83b3ff6 Merge branch 'experiment'
a6b4c97498bd301d84096da251c98a07c7723e65 beginning write support
0d52aaab4479697da7686c15f77a3d64d9165190 one more thing
6d52a271eda8725415634dd79daabbc4d9b6008e Merge branch 'experiment'
0b7434d86859cc7b8c3d5e1dddfed66ff742fcbc added a commit function
4682c3261057305bdd616e23b64b0857d832627b added a todo file
166ae0c4d3f420721acbb115cc33848dfcc2121a started write support
9fceb02d0ae598e95dc970b74767f19372d61af8 updated rakefile
964f16d36dfccde844893cac5b347e7b3d44abbc commit the todo
8a5cbc430f1a9c3d00faaeffd07798508422908a updated readme
Agora, suponha que você esqueceu de criar a tag na versão v1.2, a qual equivale ao commit “updated rakefile”. Você pode adicionar isso posteriormente. Para criar uma tag neste commit, você deve informar o checksum do commit (ou parte dele) ao final do comando:
$ git tag -a v1.2 9fceb02
Você pode ver que criou uma tag para o commit:
$ git tag
v0.1
v1.2
v1.3
v1.4
v1.4-lw
v1.5
$ git show v1.2
tag v1.2
Tagger: Scott Chacon <schacon@gee-mail.com>
Date: Mon Feb 9 15:32:16 2009 -0800
version 1.2
commit 9fceb02d0ae598e95dc970b74767f19372d61af8
Author: Magnus Chacon <mchacon@gee-mail.com>
Date: Sun Apr 27 20:43:35 2008 -0700
updated rakefile
...
Compartilhando Tags
Por padrão, o comando git push
não envia as tags para os servidores remoto.
Você terá que explicitamente enviar as tags para o servidor de compartilhamento depois de tê-las criado.
Esse processo é semelhante a compartilhar branches remotos – você pode executar git push origin [tagname]
.
$ git push origin v1.5
Counting objects: 14, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (12/12), done.
Writing objects: 100% (14/14), 2.05 KiB | 0 bytes/s, done.
Total 14 (delta 3), reused 0 (delta 0)
To git@github.com:schacon/simplegit.git
* [new tag] v1.5 -> v1.5
Se você tem muitas tags que você quer enviar de uma vez, você pode também usar a opção --tags
atrelada ao comando git push
.
Isso vai transferir todas as suas tags ainda não enviadas para o servidor remoto.
$ git push origin --tags
Counting objects: 1, done.
Writing objects: 100% (1/1), 160 bytes | 0 bytes/s, done.
Total 1 (delta 0), reused 0 (delta 0)
To git@github.com:schacon/simplegit.git
* [new tag] v1.4 -> v1.4
* [new tag] v1.4-lw -> v1.4-lw
Agora, quando alguém executar um clone ou pull a partir do seu repositório, ele vai puxar também todas as tags. ==== Checando as Tags
Você não pode realizar o checkout de uma tag no Git, uma vez que elas não podem ser movidas.
Se você quer deixar uma versão do seu repositório idêntica a uma tag especifica em seu diretório de trabalho, você pode criar um novo branch em uma tag especifica com o comando git checkout -b [branchname] [tagname]
:
$ git checkout -b version2 v2.0.0
Switched to a new branch 'version2'
Claro que se você fazer isso e realizar um commit, seu branch version2
será ligeiramente diferente do que a tag v2.0.0
assim você irá seguir em frente com suas novas modificações, então seja cuidadoso.