-
1. Primeiros Passos
- 1.1 Sobre Controle de Versão
- 1.2 Uma Breve História do Git
- 1.3 O que é Git?
- 1.4 A Linha de Comando
- 1.5 Instalando o Git
- 1.6 Configuração inicial do Git
- 1.7 Obtendo Ajuda
- 1.8 Resumo
-
2. Fundamentos do Git
-
3. Ramificação (Branching) no Git
-
4. Git no Servidor
- 4.1 Os Protocolos
- 4.2 Colocando o Git em um Servidor
- 4.3 Gerando a sua Chave Pública SSH
- 4.4 Configurando o Servidor
- 4.5 Git Daemon
- 4.6 Smart HTTP
- 4.7 GitWeb
- 4.8 GitLab
- 4.9 Opções de Hospedagem de Terceiros
- 4.10 Resumo
-
5. Git Distribuído
-
6. GitHub
-
7. Ferramentas do Git
- 7.1 Seleção de Revisão
- 7.2 Área de Stage Interativa
- 7.3 Fazendo Stash e Limpando
- 7.4 Assinando Seu Trabalho
- 7.5 Pesquisando (Searching)
- 7.6 Reescrevendo o Histórico
- 7.7 Reset Desmistificado
- 7.8 Merging Avançado
- 7.9 Rerere
- 7.10 Depurando com Git
- 7.11 Submódulos
- 7.12 Empacotando (Bundling)
- 7.13 Substituir (Replace)
- 7.14 Armazenamento de Credenciais
- 7.15 Resumo
-
8. Customizando o Git
- 8.1 Configuração do Git
- 8.2 Atributos do Git
- 8.3 Hooks do Git
- 8.4 Uma Política de Exemplo Imposta pelo Git
- 8.5 Resumo
-
9. Git e Outros Sistemas
- 9.1 Git como Cliente
- 9.2 Migrando para o Git
- 9.3 Resumo
-
10. Git Internals (Por Dentro do Git)
- 10.1 Encanamento e Porcelana (Plumbing and Porcelain)
- 10.2 Objetos do Git
- 10.3 Referências do Git
- 10.4 Arquivos de pacote (Packfiles)
- 10.5 Refspec
- 10.6 Protocolos de Transferência
- 10.7 Manutenção e Recuperação de Dados
- 10.8 Variáveis de Ambiente
- 10.9 Resumo
-
A1. Appendix A: O Git em Outros Ambientes
- A1.1 Interfaces Gráficas
- A1.2 Git no Visual Studio
- A1.3 Git no Visual Studio Code
- A1.4 Git no IntelliJ / PyCharm / WebStorm / PhpStorm / RubyMine
- A1.5 Git no Sublime Text
- A1.6 Git no Bash
- A1.7 Git no Zsh
- A1.8 Git no PowerShell
- A1.9 Resumo
-
A2. Appendix B: Incorporando o Git nos seus Aplicativos
- A2.1 Linha de Comando do Git
- A2.2 Libgit2
- A2.3 JGit
- A2.4 go-git
- A2.5 Dulwich
-
A3. Appendix C: Comandos do Git
- A3.1 Configuração e Ajustes
- A3.2 Obtendo e Criando Projetos
- A3.3 Snapshots Básicos
- A3.4 Branches e Merges
- A3.5 Compartilhando e Atualizando Projetos
- A3.6 Inspeção e Comparação
- A3.7 Depuração
- A3.8 Patches
- A3.9 E-mail
- A3.10 Sistemas Externos
- A3.11 Administração
- A3.12 Comandos de Encanamento
10.5 Git Internals (Por Dentro do Git) - Refspec
Refspec
Ao longo deste livro, usamos mapeamentos simples de branches remotos para referências locais, mas eles podem ser mais complexos. Suponha que você estava acompanhando as últimas seções e criou um pequeno repositório Git local, e agora queria adicionar um remoto (remote) a ele:
$ git remote add origin https://github.com/schacon/simplegit-progit
Executar o comando acima adiciona uma seção ao arquivo .git/config do seu repositório, especificando o nome do remoto (origin), a URL do repositório remoto e a refspec a ser usada para a busca (fetching):
[remote "origin"]
url = https://github.com/schacon/simplegit-progit
fetch = +refs/heads/*:refs/remotes/origin/*
O formato do refspec é, primeiro, um + opcional, seguido por <src>:<dst>, onde <src> é o padrão para referências no lado remoto e <dst> é onde essas referências serão rastreadas localmente.
O + diz ao Git para atualizar a referência, mesmo se não for um fast-forward.
No caso padrão que é automaticamente escrito por um comando git remote add origin, o Git busca todas as referências sob refs/heads/ no servidor e as escreve para refs/remotes/origin/ localmente.
Então, se houver um branch master no servidor, você pode acessar o log daquele branch localmente por meio de qualquer um dos seguintes:
$ git log origin/master
$ git log remotes/origin/master
$ git log refs/remotes/origin/master
Eles são todos equivalentes, porque o Git expande cada um deles para refs/remotes/origin/master.
Se, em vez disso, você quiser que o Git faça o pull apenas do branch master a cada vez, e não de todos os outros branches no servidor remoto, você pode alterar a linha de fetch para se referir apenas àquele branch:
fetch = +refs/heads/master:refs/remotes/origin/master
Esse é apenas o refspec padrão para o comando git fetch para aquele remoto.
Se você quiser fazer uma busca apenas uma vez, você também pode especificar o refspec específico na linha de comando.
Para fazer pull do branch master do remoto para origin/mymaster localmente, você pode executar:
$ git fetch origin master:refs/remotes/origin/mymaster
Você também pode especificar múltiplos refspecs. Na linha de comando, você pode fazer pull de vários branches assim:
$ git fetch origin master:refs/remotes/origin/mymaster \
topic:refs/remotes/origin/topic
From git@github.com:schacon/simplegit
! [rejected] master -> origin/mymaster (non fast forward)
* [new branch] topic -> origin/topic
Neste caso, o pull do branch master foi rejeitado porque não foi listado como uma referência fast-forward.
Você pode anular isso especificando o + na frente do refspec.
Você também pode especificar múltiplos refspecs para buscar no seu arquivo de configuração.
Se você quiser buscar sempre os branches master e experiment a partir do remote origin, adicione duas linhas:
[remote "origin"]
url = https://github.com/schacon/simplegit-progit
fetch = +refs/heads/master:refs/remotes/origin/master
fetch = +refs/heads/experiment:refs/remotes/origin/experiment
Desde o Git 2.6.0, você pode usar globs parciais no padrão para combinar múltiplos branches, então isso funciona:
fetch = +refs/heads/qa*:refs/remotes/origin/qa*
Ainda melhor, você pode usar namespaces (ou diretórios) para realizar o mesmo com mais estrutura.
Se você tem uma equipe de controle de qualidade (QA) que envia uma série de branches, e você quer obter o branch master e qualquer um dos branches da equipe de QA, mas nada mais, você pode usar uma seção de configuração assim:
[remote "origin"]
url = https://github.com/schacon/simplegit-progit
fetch = +refs/heads/master:refs/remotes/origin/master
fetch = +refs/heads/qa/*:refs/remotes/origin/qa/*
Se você tiver um processo de fluxo de trabalho complexo que tem uma equipe de controle de qualidade (QA) submetendo branches (pushing), desenvolvedores submetendo branches e equipes de integração submetendo e colaborando em branches remotas, será possível classificá-las em um namespace com facilidade dessa forma.
Submetendo Refspecs (Pushing)
É bom que você possa buscar referências no namespace dessa forma, mas como a equipe de QA consegue colocar seus branches em um namespace qa/ em primeiro lugar?
Você consegue isso usando refspecs para fazer o push.
Se a equipe de QA quiser enviar seu branch master para qa/master no servidor remoto, ela pode executar:
$ git push origin master:refs/heads/qa/master
Se eles quiserem que o Git faça isso automaticamente toda vez que executarem git push origin, eles podem adicionar um valor push ao seu arquivo de configuração:
[remote "origin"]
url = https://github.com/schacon/simplegit-progit
fetch = +refs/heads/*:refs/remotes/origin/*
push = refs/heads/master:refs/heads/qa/master
Mais uma vez, isso fará com que um git push origin envie o branch master local para o branch remoto qa/master por padrão.
|
Note
|
Não é possível usar a especificação de ref para buscar em um repositório e enviar para outro. Para obter um exemplo de como fazer isso, consulte Mantenha o seu repositório público do GitHub atualizado. |
Excluindo Referências
Você também pode usar o refspec para excluir referências do servidor remoto, executando algo assim:
$ git push origin :topic
Como o refspec é <src>:<dst>, ao deixar de fora a parte <src>, isso basicamente diz para transformar o branch topic no remoto em nada, o que a exclui.
Ou você pode usar a sintaxe mais nova (disponível desde o Git v1.7.0):
$ git push origin --delete topic