-
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 Instalar o Git
- 1.6 Configuração Inicial do Git
- 1.7 Pedindo Ajuda
- 1.8 Resumo
-
2. NoƧƵes BƔsicas do Git
- 2.1 Obtendo um Repositório Git
- 2.2 Recording Changes to the Repository
- 2.3 Veja o Histórico de Confirmação
- 2.4 Desfazer Coisas
- 2.5 Working with Remotes
- 2.6 Tagging
- 2.7 Alias Git
- 2.8 Resumo
-
3. Ramificação do Git
- 3.1 Branches in a Nutshell
- 3.2 Basic Branching and Merging
- 3.3 Branch Management
- 3.4 Branching Workflows
- 3.5 Remote Branches
- 3.6 Rebasing
- 3.7 Resume
-
4. Git no Servidor
- 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 OpƧƵes Hospedadas de Terceiros
- 4.10 Resumo
-
5. Git DistribuĆdo
- 5.1 Distributed Workflows
- 5.2 Contributing to a Project
- 5.3 Maintaining a Project
- 5.4 Resumo
-
6. GitHub
-
7. Ferramentas do Git
- 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 Resumo
-
8. Personalizar o Git
- 8.1 Git Configuration
- 8.2 Git Attributes
- 8.3 Git Hooks
- 8.4 An Example Git-Enforced Policy
- 8.5 Resumo
-
9. O Git e Outros Sistemas
- 9.1 O Git como Cliente
- 9.2 Migrar para o Git
- 9.3 Resumo
-
10. Internos do Git
- 10.1 Plumbing and Porcelain
- 10.2 Git Objects
- 10.3 Git References
- 10.4 Packfiles
- 10.5 The Refspec
- 10.6 Transfer Protocols
- 10.7 Maintenance and Data Recovery
- 10.8 Environment Variables
- 10.9 Resumo
-
A1. Appendix A: Git em Outros Ambientes
- A1.1 Graphical Interfaces
- A1.2 Git no Visual Studio
- A1.3 Git no Eclipse
- A1.4 Git in Bash
- A1.5 Git no Zsh
- A1.6 Git no Powershell
- A1.7 Resumo
-
A2. Appendix B: Incorporar o Git nos teus Aplicativos
- A2.1 Linha de comando 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 NoƧƵes BƔsicas do Git - Tagging
Tagging
Como a maioria dos VCSs, Git tem a habilidade de marcar pontos especĆficos no histórico como sendo importantes. Normalmente, as pessoas usam esta funcionalidade para marcar os pontos de lanƧamento (v1.0 e assim por diante). Nesta seção, aprenderĆ”s como listar as tags disponĆveis, como criar novas tags e quais sĆ£o os diferentes tipos de tags.
Listar as tuas tags
Listar as tags disponĆveis no Git Ć© direto.
Basta digitar git tag
(com opcional -l
ou --list
):
$ git tag
v0.1
v1.3
Este comando lista as tags em ordem alfabética; A ordem em que aparecem não tem importância real.
Tu podes procurar por tags que correspondam a um padrĆ£o especĆfico. O repositório fonte Git, por exemplo, contĆ©m mais de 500 tags. Se tu só estiveres interessado em olhar para a sĆ©rie 1.8.5, podes executar isto:
$ 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
-l
ou --list
Se tu quiseres apenas a lista completa de tags, executar o comando git tag
implica implicitamente que tu pretendes uma lista e fornece uma; O uso de -l
ou --list
neste caso Ć© opcional.
Se, no entanto, estiveres a fornecer um padrão de wildcard para coincidir com os nomes das tags, o uso de -l
ou --list
é obrigatório.
Criar Tags
O Git suporta dois tipos de tags: lightweight e annoteted.
Uma tag leve Ć© muito parecida com um ramo que nĆ£o mudaāāāĆ© apenas um ponteiro para um commit especĆfico.
As tags anotadas, no entanto, sĆ£o armazenadas como objetos completos na base de dados Git. Elas sĆ£o assinaladas; conter o nome do tagger, o email e a data; ter uma mensagem de tagging; e pode ser assinado e verificado com o GNU Privacy Guard (GPG). Geralmente, Ć© recomendĆ”vel que cries tags anotadas para que possas ter toda esta informação; mas se tu quiseres uma tag temporĆ”ria ou, por algum motivo, nĆ£o quiseres manter as outras informaƧƵes, as tags leves tambĆ©m estĆ£o disponĆveis.
Tags Anotadas
Criar uma tag anotada no Git Ć© simples.
A maneira mais fƔcil Ʃ especificar -a
quando executas o comando tag
:
$ git tag -a v1.4 -m "minha versão 1.4"
$ git tag
v0.1
v1.3
v1.4
O -m
especifica uma mensagem de tagging, que Ć© armazenada com a tag.
Se não especificares uma mensagem para uma tag anotada, o Git lança o teu editor para que possas digitÔ-lo.
Podes ver os dados da tag juntamente com o commit que foi tagget usando o comando git show
:
$ git show v1.4
tag v1.4
Tagger: Ben Straub <ben@straub.cc>
Data: Sab Mai 3 20:19:12 2014 -0700
a minha versão 1.4
commit ca82a6dff817ec66f44342007202690a93763949
Autor: Scott Chacon <schacon@gee-mail.com>
Data: Seg Mar 17 21:52:11 2008 -0700
alterou o número da versão
Isto mostra a informação do tagger, a data em que o commit foi tagget e a mensagem de anotação antes de mostrar as informações de confirmação.
Tags Leves
Outra maneira de marcar compromissos Ć© com uma tag leve.
Esta Ć© basicamente a soma da verificação do compromisso armazenada num arquivoāāānenhuma outra informação Ć© mantida.
Para criar uma tag leve, não forneçe nenhuma das opções -a
, -s
ou -m
, basta fornecer um nome de tag:
$ git tag v1.4-lw
$ git tag
v0.1
v1.3
v1.4
v1.4-lw
v1.5
Desta vez, se tu executares o git show
na tag, não verÔs as informações adicionais da tag.
O comando mostra apenas o commit:
$ git show v1.4-lw
commit ca82a6dff817ec66f44342007202690a93763949
Autor: Scott Chacon <schacon@gee-mail.com>
Data: Seg Mar 17 21:52:11 2008 -0700
alterou o número da versão
Tagging Mais Tarde
Também podes marcar compromissos depois de passares por eles. Supões que o teu histórico de confirmação se pareça com isto:
$ git log --pretty=oneline
15027957951b64cf874c3557a0f3547bd83b3ff6 Merge branch 'experiĆŖncia'
a6b4c97498bd301d84096da251c98a07c7723e65 inĆcio do suporte de escrita
0d52aaab4479697da7686c15f77a3d64d9165190 mais uma coisa
6d52a271eda8725415634dd79daabbc4d9b6008e Merge branch 'experiĆŖncia'
0b7434d86859cc7b8c3d5e1dddfed66ff742fcbc adicionou uma função de commit
4682c3261057305bdd616e23b64b0857d832627b adicionou um arquivo todo
166ae0c4d3f420721acbb115cc33848dfcc2121a comeƧou a gravar suporte
9fceb02d0ae598e95dc970b74767f19372d61af8 arquivo de rake atualizado
964f16d36dfccde844893cac5b347e7b3d44abbc commit o todo
8a5cbc430f1a9c3d00faaeffd07798508422908a leia-me atualizado
Agora, supõe que te tenhas esquecido de marcar o projeto na v1.2, que estava no commit de "ficheiro rake atualizado". Tu podes adicionÔ-lo após o fato. Para marcar este commit, tu especificas a soma de verificação de commit (ou parte dela) no final do comando:
$ git tag -a v1.2 9fceb02
Podes ver que marcaste 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>
Data: Seg Fev 9 15:32:16 2009 -0800
versão 1.2
commit 9fceb02d0ae598e95dc970b74767f19372d61af8
Autor: Magnus Chacon <mchacon@gee-mail.com>
Data: Dom Abr 27 20:43:35 2008 -0700
arquivo de rake atualizado
...
Partilhar Tags
Por padrão, o comando git push
não transfere tags para os servidores remotos.
Tu precisarƔs empurrar explicitamente as tags para um servidor compartilhado depois de as ter criado.
Este processo Ć© como compartilhar filiais remotosāāāpodes executar origem git push <tagname>
.
$ origem git push v1.5
Contando objetos: 14, feito.
Compressão Delta usando até 8 tópicos.
Comprimir objetos: 100% (12/12), feito.
Escrevendo objetos: 100% (14/14), 2.05 KiB | 0 bytes/s, feito.
Total 14 (delta 3), reutilizado 0 (delta 0).
Para git@github.com:schacon/simplegit.git
* [nova tag] v1.5 -> v1.5
Se tu tens muitas tags que desejas pressionar de uma só vez, também podes usar a opção --tags
para o comando` git push`.
Isto transferirÔ todas as tuas tags para o servidor remoto que ainda não estão lÔ.
$ origem git push --tags
Contando objetos: 1, feito.
Escrevendo objetos: 100% (1/1), 160 bytes | 0 bytes/s, feito.
Total 1 (delta 0), reutilizado 0 (delta 0)
Para git@github.com:schacon/simplegit.git
* [new tag] v1.4 -> v1.4
* [new tag] v1.4-lw -> v1.4-lw
Agora, quando alguém clona ou puxa do teu repositório, eles também receberão todas as tuas tags.
Verificando as Tags
Se tu quiseres veres as versƵes dos arquivos que uma tag estĆ” a apontar para, tu podes fazer um check-in git, embora isto coloca o teu repositório no estado āCABEĆA destacadaā, que tem alguns efeitos secundĆ”rios:
$ saindo do git 2.0.0
Nota: saindo '2.0.0'.
Tu estÔs no estado "cabeça destacada". Podes olhar ao redor, fazer experiências
muda e compromete-os, e podes descartar quaisquer compromissos que tu fizeres neste
estado sem afetar nenhum ramo executando outro checkout.
Se tu quiseres criar um novo ramo para manteres os compromissos que criaste, podes
fazer isto (agora ou mais tarde) usando -b com o comando checkout novamente. Exemplo:
git checkout -b <novo-ramo>
CABEĆA estĆ” agora em 99ada87... Merge pull request #89 de schacon/appendix-final
$ git checkout 2.0-beta-0.1
A posição da CABEĆA tem 99ada87... Merge pull request #89 de schacon/appendix-final
CABEĆA estĆ” agora em df3f601... adiciona atlas.json e imagem de capa
No estado āCABEĆA destacadaā, se fizeres alteraƧƵes e, em seguida, criar um commit, a tag permanecerĆ” igual, mas a tua nova confirmação nĆ£o pertencerĆ” a nenhum ramo e serĆ” inacessĆvel, exceto pelo hash de commit exato. Assim, se tu precisares de fazer alteraƧƵesāāādigamos que tu estĆ”s corrigindo um bug numa versĆ£o mais antiga, por exemploāāātu geralmente quererĆ”s criar uma filial:
$ git checkout -b versão2 v2.0.0
Mudou para um novo ramo'versão2'
Se tu fizeres isto e fazeres um commit, o teu ramo versão2
serĆ” ligeiramente diferente do teu tag v2.0.0
, uma vez que avançarÔ com as tuas novas mudanças, então tem cuidado.