Ao longo do livro, apresentamos dezenas de comandos do Git e nos esforçamos para introduzi-los dentro de uma espécie de narrativa, acrescentando novos comandos à história aos poucos. No entanto, isso deixa os exemplos de uso dos comandos um tanto dispersos por todo o livro.
Neste apêndice, percorreremos todos os comandos do Git abordados ao longo do livro, agrupados aproximadamente de acordo com sua finalidade. Falaremos, em linhas gerais, sobre o que cada comando faz e indicaremos em que parte do livro você pode encontrar exemplos de seu uso.
|
Tip
|
Você pode abreviar opções longas.
Por exemplo, você pode digitar |
Há dois comandos usados com muita frequência, desde as primeiras invocações do Git até ajustes e consultas comuns do dia a dia: config e help.
O Git tem uma forma padrão de realizar centenas de tarefas. Para muitas delas, você pode instruir o Git a adotar outra forma como padrão ou definir suas preferências. Isso abrange desde informar seu nome ao Git até preferências específicas de cores no terminal ou do editor que você usa. Esse comando lê e grava em vários arquivos, permitindo definir valores globalmente ou para repositórios específicos.
O comando git config foi usado em quase todos os capítulos do livro.
Em ch01-getting-started.asc, nós o usamos para especificar nosso nome, endereço de e-mail e editor preferido antes mesmo de começar a usar o Git.
Em ch02-git-basics-chapter.asc, mostramos como usá-lo para criar atalhos de comandos que se expandem em longas sequências de opções, evitando que você precise digitá-las todas as vezes.
Em ch03-git-branching.asc, nós o usamos para tornar --rebase o padrão ao executar git pull.
Em ch07-git-tools.asc, nós o usamos para configurar um armazenamento padrão para suas senhas HTTP.
Em ch08-customizing-git.asc, mostramos como configurar filtros smudge e clean no conteúdo que entra e sai do Git.
Por fim, praticamente toda a seção ch08-customizing-git.asc é dedicada ao comando.
Como complemento às instruções de configuração em ch01-getting-started.asc, muitos editores podem ser configurados da seguinte maneira:
core.editor| Editor | Comando de configuração |
|---|---|
Atom |
|
BBEdit (macOS, com ferramentas de linha de comando) |
|
Emacs |
|
Gedit (Linux) |
|
Gvim (Windows de 64 bits) |
|
Helix |
|
Kate (Linux) |
|
nano |
|
Notepad (Windows de 64 bits) |
|
Notepad++ (Windows de 64 bits) |
|
Scratch (Linux) |
|
Sublime Text (macOS) |
|
Sublime Text (Windows de 64 bits) |
|
TextEdit (macOS) |
|
Textmate |
|
Textpad (Windows de 64 bits) |
|
UltraEdit (Windows de 64 bits) |
|
Vim |
|
Visual Studio Code |
|
VSCodium (binários de software livre/de código aberto do VSCode) |
|
WordPad |
|
Xi |
|
|
Note
|
Se você usa um editor de 32 bits em um sistema Windows de 64 bits, o programa será instalado em |
O comando git help é usado para exibir toda a documentação distribuída com o Git sobre qualquer comando.
Embora este apêndice ofereça uma visão geral aproximada da maioria dos comandos mais populares, você sempre pode executar git help <command> para obter uma lista completa de todas as opções e flags possíveis de cada comando.
Apresentamos o comando git help em ch01-getting-started.asc e mostramos como usá-lo para encontrar mais informações sobre o git shell em ch04-git-on-the-server.asc.
Há duas maneiras de obter um repositório Git. Uma é copiá-lo de um repositório existente na rede ou em outro local; a outra é criar um novo em um diretório existente.
Para transformar um diretório em um novo repositório Git e começar a controlar suas versões, basta executar git init.
Apresentamos esse comando pela primeira vez em ch02-git-basics-chapter.asc, onde mostramos como criar um repositório inteiramente novo para começar a trabalhar.
Em ch03-git-branching.asc, falamos brevemente sobre como alterar o nome padrão do branch, deixando de usar “master”.
Em ch04-git-on-the-server.asc, usamos esse comando para criar um repositório bare vazio para um servidor.
Por fim, em ch10-git-internals.asc, examinamos alguns detalhes do que ele realmente faz nos bastidores.
O comando git clone funciona, na verdade, como uma espécie de wrapper para vários outros comandos.
Ele cria um novo diretório, entra nele e executa git init para transformá-lo em um repositório Git vazio, adiciona um remote (git remote add) para a URL fornecida (chamado origin por padrão), executa git fetch desse repositório remoto e então faz checkout do commit mais recente no seu diretório de trabalho com git checkout.
O comando git clone é usado em dezenas de pontos ao longo do livro, mas listaremos apenas alguns dos mais interessantes.
Ele é apresentado e explicado em ch02-git-basics-chapter.asc, onde examinamos alguns exemplos.
Em ch04-git-on-the-server.asc, vemos como usar a opção --bare para criar uma cópia de um repositório Git sem diretório de trabalho.
Em ch07-git-tools.asc, nós o usamos para desempacotar um repositório Git armazenado em um bundle.
Por fim, em ch07-git-tools.asc, conhecemos a opção --recurse-submodules, que simplifica um pouco a clonagem de um repositório com submódulos.
Embora seja usado em muitos outros pontos do livro, esses são os casos mais singulares ou aqueles em que ele é usado de maneiras um pouco diferentes.
Para o fluxo básico de preparar conteúdo e fazer commit dele no histórico, são necessários apenas alguns comandos básicos.
O comando git add adiciona conteúdo do diretório de trabalho à área de preparação (ou “index”) para o próximo commit.
Por padrão, quando o comando git commit é executado, ele considera apenas essa área de preparação; portanto, git add é usado para definir exatamente como deve ser o snapshot do próximo commit.
Esse é um comando extremamente importante no Git, mencionado ou usado dezenas de vezes neste livro. Examinaremos rapidamente alguns de seus usos específicos.
Apresentamos e explicamos git add em detalhes pela primeira vez em ch02-git-basics-chapter.asc.
Em ch03-git-branching.asc, mencionamos como usá-lo para resolver conflitos de merge.
Em ch07-git-tools.asc, vemos como usá-lo para preparar interativamente apenas partes específicas de um arquivo modificado.
Por fim, em ch10-git-internals.asc, nós o reproduzimos em baixo nível para que você tenha uma ideia do que ele faz nos bastidores.
O comando git status mostra os diferentes estados dos arquivos no diretório de trabalho e na área de preparação.
Quais arquivos foram modificados e não estão preparados e quais estão preparados, mas ainda não foram commitados.
Em sua forma normal, ele também mostra algumas orientações básicas sobre como mover arquivos entre esses estados.
Abordamos status pela primeira vez em ch02-git-basics-chapter.asc, tanto em sua forma básica quanto na simplificada.
Embora seja usado ao longo de todo o livro, praticamente tudo o que você pode fazer com o comando git status é tratado ali.
O comando git diff é usado quando você quer ver as diferenças entre duas árvores quaisquer.
Pode ser a diferença entre seu ambiente de trabalho e a área de preparação (apenas git diff), entre a área de preparação e o último commit (git diff --staged) ou entre dois commits (git diff master branchB).
Vemos os usos básicos de git diff pela primeira vez em ch02-git-basics-chapter.asc, onde mostramos como identificar quais alterações estão preparadas e quais ainda não estão.
Em ch05-distributed-git.asc, nós o usamos com a opção --check para procurar possíveis problemas de espaço em branco antes do commit.
Em ch05-distributed-git.asc, vemos como conferir as diferenças entre branches com mais eficiência usando a sintaxe git diff A…B.
Em ch07-git-tools.asc, nós o usamos para ignorar diferenças de espaço em branco com -b e mostramos como comparar diferentes estágios de arquivos em conflito com --theirs, --ours e --base.
Por fim, em ch07-git-tools.asc, nós o usamos com --submodule para comparar alterações em submódulos de maneira eficaz.
O comando git difftool simplesmente inicia uma ferramenta externa para mostrar a diferença entre duas árvores, caso você queira usar algo diferente do comando git diff integrado.
Nós o mencionamos apenas brevemente em ch02-git-basics-chapter.asc.
O comando git commit pega todo o conteúdo de arquivos preparado com git add, registra um novo snapshot permanente no banco de dados e então move até ele o ponteiro do branch atual.
Abordamos os fundamentos de fazer commits pela primeira vez em ch02-git-basics-chapter.asc.
Ali também demonstramos como usar a flag -a para pular a etapa de git add nos fluxos de trabalho cotidianos e como usar a flag -m para fornecer uma mensagem de commit na linha de comando em vez de abrir um editor.
Em ch02-git-basics-chapter.asc, abordamos o uso da opção --amend para refazer o commit mais recente.
Em ch03-git-branching.asc, entramos em muito mais detalhes sobre o que git commit faz e por que funciona dessa maneira.
Em ch07-git-tools.asc, vimos como assinar commits criptograficamente com a flag -S.
Por fim, em ch10-git-internals.asc, examinamos o que o comando git commit faz em segundo plano e como ele realmente é implementado.
O comando git reset é usado principalmente para desfazer coisas, como o verbo talvez já indique.
Ele move o ponteiro HEAD, opcionalmente altera o index ou a área de preparação e também pode alterar o diretório de trabalho se você usar --hard.
Essa última opção faz com que o comando possa eliminar seu trabalho se for usado incorretamente; portanto, certifique-se de entendê-lo antes de usá-lo.
Abordamos pela primeira vez o uso mais simples de git reset em ch02-git-basics-chapter.asc, onde o usamos para retirar da área de preparação um arquivo no qual havíamos executado git add.
Depois, abordamos o comando em bastante detalhe em ch07-git-tools.asc, seção inteiramente dedicada a explicá-lo.
Em ch07-git-tools.asc, usamos git reset --hard para abortar um merge; ali também usamos git merge --abort, que funciona como uma espécie de wrapper para o comando git reset.
O comando git rm é usado para remover arquivos da área de preparação e do diretório de trabalho do Git.
Ele é semelhante a git add, pois prepara a remoção de um arquivo para o próximo commit.
Abordamos o comando git rm em algum detalhe em ch02-git-basics-chapter.asc, incluindo a remoção recursiva de arquivos e, com --cached, a remoção apenas da área de preparação, mantendo-os no diretório de trabalho.
O único outro uso diferente de git rm no livro aparece em ch10-git-internals.asc, onde usamos e explicamos brevemente --ignore-unmatch ao executar git filter-branch; essa opção simplesmente evita um erro quando o arquivo que tentamos remover não existe.
Isso pode ser útil em scripts.
O comando git mv é um pequeno atalho conveniente para mover um arquivo e então executar git add no novo arquivo e git rm no antigo.
Mencionamos esse comando apenas brevemente em ch02-git-basics-chapter.asc.
O comando git clean é usado para remover arquivos indesejados do diretório de trabalho.
Isso pode incluir artefatos temporários de build ou arquivos de conflito de merge.
Em ch07-git-tools.asc, abordamos muitas das opções e situações em que você pode usar o comando clean.
Poucos comandos implementam a maior parte das funcionalidades de branch e merge do Git.
O comando git branch funciona, na verdade, como uma ferramenta de gerenciamento de branches.
Ele pode listar seus branches, criar um novo branch, excluir branches e renomeá-los.
A maior parte de ch03-git-branching.asc é dedicada ao comando branch, que é usado ao longo de todo o capítulo.
Nós o apresentamos pela primeira vez em ch03-git-branching.asc e examinamos a maioria de seus outros recursos (listagem e exclusão) em ch03-git-branching.asc.
Em ch03-git-branching.asc, usamos a opção git branch -u para configurar um branch de rastreamento.
Por fim, em ch10-git-internals.asc, examinamos parte do que ele faz em segundo plano.
O comando git checkout é usado para alternar entre branches e fazer checkout de conteúdo no diretório de trabalho.
Encontramos o comando pela primeira vez em ch03-git-branching.asc, junto com o comando git branch.
Em ch03-git-branching.asc, vemos como usá-lo para começar a rastrear branches com a flag --track.
Em ch07-git-tools.asc, nós o usamos com --conflict=diff3 para reintroduzir conflitos em arquivos.
Em ch07-git-tools.asc, examinamos mais detalhadamente sua relação com git reset.
Por fim, em ch10-git-internals.asc, abordamos alguns detalhes de implementação.
A ferramenta git merge é usada para mesclar um ou mais branches no branch em que você fez checkout.
Em seguida, ela avança o branch atual até o resultado do merge.
O comando git merge foi apresentado pela primeira vez em ch03-git-branching.asc.
Embora seja usado em vários pontos do livro, há poucas variações do comando merge — em geral, apenas git merge <branch> com o nome do único branch que você quer mesclar.
No final de ch05-distributed-git.asc, abordamos como fazer um merge squash (no qual o Git mescla o trabalho, mas o trata como um único novo commit, sem registrar o histórico do branch que está sendo mesclado).
Em ch07-git-tools.asc, examinamos muitos aspectos do processo e do comando de merge, incluindo o comando -Xignore-space-change e a flag --abort para abortar um merge problemático.
Em ch07-git-tools.asc, aprendemos a verificar assinaturas antes do merge quando o projeto usa assinaturas GPG.
Por fim, em ch07-git-tools.asc, aprendemos sobre merges de subárvores.
O comando git mergetool simplesmente inicia um auxiliar externo de merge caso você tenha problemas com um merge no Git.
Nós o mencionamos rapidamente em ch03-git-branching.asc e detalhamos como implementar sua própria ferramenta externa de merge em ch08-customizing-git.asc.
O comando git log é usado para mostrar o histórico registrado e alcançável de um projeto, retrocedendo a partir do snapshot do commit mais recente.
Por padrão, ele mostra apenas o histórico do branch atual, mas você pode fornecer heads ou branches diferentes, inclusive vários deles, como pontos de partida para percorrer o histórico.
Ele também é usado com frequência para mostrar diferenças entre dois ou mais branches no nível dos commits.
Esse comando é usado em quase todos os capítulos do livro para demonstrar o histórico de um projeto.
Apresentamos o comando e o abordamos com alguma profundidade em ch02-git-basics-chapter.asc.
Ali examinamos as opções -p e --stat para ter uma ideia do que foi introduzido em cada commit e as opções --pretty e --oneline para visualizar o histórico de forma mais concisa, além de algumas opções simples de filtragem por data e autor.
Em ch03-git-branching.asc, nós o usamos com a opção --decorate para visualizar facilmente a localização dos ponteiros dos branches e também com a opção --graph para ver como são históricos divergentes.
Em ch05-distributed-git.asc e ch07-git-tools.asc, abordamos a sintaxe branchA..branchB para usar o comando git log e ver quais commits são exclusivos de um branch em relação a outro.
Em ch07-git-tools.asc, examinamos isso em bastante detalhe.
Em ch07-git-tools.asc e ch07-git-tools.asc, abordamos o uso do formato branchA…branchB e da sintaxe --left-right para ver o que está em um branch ou no outro, mas não em ambos.
Em ch07-git-tools.asc, também vemos como usar a opção --merge para ajudar a depurar conflitos de merge, bem como a opção --cc para examinar conflitos de commits de merge no histórico.
Em ch07-git-tools.asc, usamos a opção -g para visualizar o reflog do Git por meio dessa ferramenta, em vez de percorrer branches.
Em ch07-git-tools.asc, examinamos o uso das opções -S e -L para realizar buscas bastante sofisticadas por algo que ocorreu no histórico do código, como visualizar o histórico de uma função.
Em ch07-git-tools.asc, vemos como usar --show-signature para adicionar uma informação de validação a cada commit na saída de git log, conforme ele tenha ou não uma assinatura válida.
O comando git stash é usado para armazenar temporariamente trabalho não commitado, permitindo limpar o diretório de trabalho sem precisar fazer commit de trabalho inacabado em um branch.
Isso é abordado praticamente por completo em ch07-git-tools.asc.
O comando git tag é usado para criar um marcador permanente em um ponto específico do histórico do código.
Em geral, isso é usado para itens como releases.
Esse comando é apresentado e abordado em detalhes em ch02-git-basics-chapter.asc, e nós o usamos na prática em ch05-distributed-git.asc.
Em ch07-git-tools.asc, também abordamos como criar uma tag assinada com GPG usando a flag -s e como verificá-la com a flag -v.
Não há muitos comandos do Git que acessam a rede; quase todos operam no banco de dados local. Quando você estiver pronto para compartilhar seu trabalho ou obter alterações de outro local, há alguns comandos que lidam com repositórios remotos.
O comando git fetch se comunica com um repositório remoto, busca todas as informações presentes nele que ainda não estão no repositório atual e as armazena no banco de dados local.
Vemos esse comando pela primeira vez em ch02-git-basics-chapter.asc e encontramos outros exemplos de seu uso em ch03-git-branching.asc.
Também o usamos em vários exemplos de ch05-distributed-git.asc.
Em ch06-github.asc, nós o usamos para buscar uma única referência específica fora do namespace padrão; em ch07-git-tools.asc, vemos como fazer fetch a partir de um bundle.
Em ch10-git-internals.asc, configuramos refspecs altamente personalizados para fazer git fetch se comportar de maneira um pouco diferente do padrão.
O comando git pull é basicamente uma combinação de git fetch e git merge: o Git faz fetch do remote especificado e tenta mesclar imediatamente o resultado no branch atual.
Nós o apresentamos rapidamente em ch02-git-basics-chapter.asc e mostramos como ver o que será mesclado ao executá-lo em ch02-git-basics-chapter.asc.
Em ch03-git-branching.asc, também vemos como usá-lo para ajudar com dificuldades de rebase.
Em ch05-distributed-git.asc, mostramos como usá-lo com uma URL para obter alterações de forma pontual.
Por fim, em ch07-git-tools.asc, mencionamos brevemente que você pode usar a opção --verify-signatures para verificar se os commits obtidos por pull foram assinados com GPG.
O comando git push é usado para se comunicar com outro repositório, calcular o que existe no banco de dados local e não existe no remoto e então enviar a diferença ao outro repositório.
Ele exige acesso de gravação ao outro repositório e, por isso, normalmente requer algum tipo de autenticação.
Vemos o comando git push pela primeira vez em ch02-git-basics-chapter.asc.
Ali abordamos os fundamentos de fazer push de um branch para um repositório remoto.
Em ch03-git-branching.asc, aprofundamos um pouco o push de branches específicos e, em ch03-git-branching.asc, vemos como configurar branches de rastreamento para fazer push automaticamente.
Em ch03-git-branching.asc, usamos a flag --delete para excluir um branch no servidor com git push.
Ao longo de ch05-distributed-git.asc, vemos vários exemplos de uso de git push para compartilhar trabalho em branches por meio de vários remotes.
Em ch02-git-basics-chapter.asc, vemos como usá-lo com a opção --tags para compartilhar as tags que você criou.
Em ch07-git-tools.asc, usamos a opção --recurse-submodules para verificar se todo o trabalho dos submódulos foi publicado antes de fazer push do superprojeto, o que pode ser muito útil ao usar submódulos.
Em ch08-customizing-git.asc, falamos brevemente sobre o hook pre-push, um script que podemos configurar para ser executado antes da conclusão de um push e verificar se ele deve ser permitido.
Por fim, em ch10-git-internals.asc, vemos como fazer push com um refspec completo em vez dos atalhos gerais usados normalmente. Isso permite especificar com muita precisão qual trabalho você deseja compartilhar.
O comando git remote é uma ferramenta para gerenciar seu registro de repositórios remotos.
Ele permite salvar URLs longas com nomes curtos, como “origin”, para que você não precise digitá-las o tempo todo.
Você pode ter vários desses registros, e o comando git remote é usado para adicioná-los, alterá-los e excluí-los.
Esse comando é abordado em detalhes em ch02-git-basics-chapter.asc, incluindo como listar, adicionar, remover e renomear remotes.
Ele também é usado em quase todos os capítulos seguintes do livro, mas sempre no formato padrão git remote add <name> <url>.
O comando git archive é usado para criar um arquivo contendo um snapshot específico do projeto.
Em ch05-distributed-git.asc, usamos git archive para criar um tarball de um projeto a ser compartilhado.
O comando git submodule é usado para gerenciar repositórios externos dentro de um repositório comum.
Eles podem conter bibliotecas ou outros tipos de recursos compartilhados.
O comando submodule possui vários subcomandos (add, update, sync etc.) para gerenciar esses recursos.
Esse comando só é mencionado e inteiramente abordado em ch07-git-tools.asc.
O comando git show pode exibir um objeto Git de maneira simples e legível para pessoas.
Normalmente, você o usaria para mostrar informações sobre uma tag ou um commit.
Nós o usamos pela primeira vez em ch02-git-basics-chapter.asc para exibir informações de tags anotadas.
Mais adiante, nós o usamos bastante em ch07-git-tools.asc para mostrar os commits aos quais nossas várias seleções de revisão são resolvidas.
Um dos usos mais interessantes de git show aparece em ch07-git-tools.asc, onde extraímos conteúdo específico de arquivos em vários estágios durante um conflito de merge.
O comando git shortlog é usado para resumir a saída de git log.
Ele aceita muitas das mesmas opções que o comando git log, mas, em vez de listar todos os commits, apresenta um resumo deles agrupado por autor.
Em ch05-distributed-git.asc, mostramos como usá-lo para criar um bom changelog.
O comando git describe recebe qualquer coisa que possa ser resolvida em um commit e produz uma string razoavelmente legível que não mudará.
É uma maneira de obter uma descrição do commit tão inequívoca quanto seu SHA-1, mas mais compreensível.
Em ch05-distributed-git.asc e ch05-distributed-git.asc, usamos git describe para obter uma string com a qual nomear nosso arquivo de lançamento.
O Git possui alguns comandos que ajudam a depurar um problema no código. Eles permitem desde descobrir onde algo foi introduzido até identificar quem o introduziu.
A ferramenta git bisect é extremamente útil para depuração e permite descobrir qual commit específico introduziu primeiro um bug ou problema por meio de uma busca binária automática.
Ela é inteiramente abordada em ch07-git-tools.asc e só é mencionada nessa seção.
O comando git blame anota cada linha de um arquivo com o commit que a alterou por último e com a pessoa que criou esse commit.
Isso ajuda a encontrar a pessoa a quem pedir mais informações sobre uma seção específica do código.
Ele é abordado em ch07-git-tools.asc e só é mencionado nessa seção.
O comando git grep pode ajudar a encontrar qualquer string ou expressão regular em qualquer arquivo do código-fonte, até mesmo em versões antigas do projeto.
Ele é abordado em ch07-git-tools.asc e só é mencionado nessa seção.
Alguns comandos do Git se concentram no conceito de considerar os commits pelas alterações que introduzem, como se a sequência de commits fosse uma série de patches. Esses comandos ajudam a gerenciar seus branches dessa maneira.
O comando git cherry-pick é usado para pegar a alteração introduzida em um único commit do Git e tentar reintroduzi-la como um novo commit no branch atual.
Isso pode ser útil para trazer individualmente apenas um ou dois commits de um branch, em vez de mesclar o branch e trazer todas as alterações.
O cherry-pick é descrito e demonstrado em ch05-distributed-git.asc.
O comando git rebase é basicamente um cherry-pick automatizado.
Ele determina uma série de commits e então aplica cherry-pick a cada um deles, na mesma ordem, em outro local.
O rebase é abordado em detalhes em ch03-git-branching.asc, incluindo os problemas de colaboração envolvidos ao fazer rebase de branches que já são públicos.
Em ch07-git-tools.asc, nós o usamos na prática em um exemplo que divide o histórico em dois repositórios separados, usando também a flag --onto.
Em ch07-git-tools.asc, examinamos como lidar com um conflito de merge durante um rebase.
Em ch07-git-tools.asc, também o usamos em um modo interativo para scripts com a opção -i.
O comando git revert é essencialmente um git cherry-pick ao contrário.
Ele cria um novo commit que aplica exatamente o oposto da alteração introduzida no commit selecionado, na prática desfazendo ou revertendo essa alteração.
Em ch07-git-tools.asc, usamos esse comando para desfazer um commit de merge.
Muitos projetos Git, incluindo o próprio Git, são mantidos inteiramente por meio de listas de discussão. O Git possui várias ferramentas integradas que facilitam esse processo, desde a geração de patches que você pode enviar facilmente por e-mail até a aplicação desses patches a partir de uma caixa de correio.
O comando git apply aplica um patch criado com o comando git diff ou até mesmo com o GNU diff.
Ele é semelhante ao que o comando patch faria, com algumas pequenas diferenças.
Em ch05-distributed-git.asc, demonstramos seu uso e as circunstâncias em que ele pode ser apropriado.
O comando git am é usado para aplicar patches provenientes de uma caixa de entrada de e-mail, especificamente uma no formato mbox.
Isso é útil para receber patches por e-mail e aplicá-los facilmente ao projeto.
Em ch05-distributed-git.asc, abordamos o uso e o fluxo de trabalho de git am, incluindo as opções --resolved, -i e -3.
Também há vários hooks que você pode usar para ajudar no fluxo de trabalho de git am, todos abordados em ch08-customizing-git.asc.
Em ch06-github.asc, também o usamos para aplicar alterações de um Pull Request do GitHub formatadas como patch.
O comando git format-patch é usado para gerar uma série de patches no formato mbox, devidamente formatados para envio a uma lista de discussão.
Em ch05-distributed-git.asc, examinamos um exemplo de contribuição para um projeto usando a ferramenta git format-patch.
O comando git imap-send envia uma caixa de correio gerada com git format-patch para uma pasta de rascunhos IMAP.
Em ch05-distributed-git.asc, examinamos um exemplo de contribuição para um projeto por meio do envio de patches com a ferramenta git imap-send.
O comando git send-email é usado para enviar por e-mail patches gerados com git format-patch.
Em ch05-distributed-git.asc, examinamos um exemplo de contribuição para um projeto por meio do envio de patches com a ferramenta git send-email.
O comando git request-pull é usado simplesmente para gerar um modelo de corpo de mensagem a ser enviado por e-mail a alguém.
Se você tem um branch em um servidor público e quer informar a alguém como integrar essas alterações sem enviar os patches por e-mail, pode executar esse comando e enviar a saída para a pessoa que deverá incorporar as alterações.
Em ch05-distributed-git.asc, demonstramos como usar git request-pull para gerar uma mensagem de pull.
O Git inclui alguns comandos para integração com outros sistemas de controle de versão.
O comando git svn é usado para se comunicar, como cliente, com o sistema de controle de versão Subversion.
Isso significa que você pode usar o Git para fazer checkout a partir de um servidor Subversion e enviar commits para ele.
Esse comando é abordado em profundidade em ch09-git-and-other-systems.asc.
Para outros sistemas de controle de versão ou para importar de praticamente qualquer formato, você pode usar git fast-import para mapear rapidamente o outro formato para algo que o Git possa registrar com facilidade.
Esse comando é abordado em profundidade em ch09-git-and-other-systems.asc.
Se você administra um repositório Git ou precisa fazer um reparo de grande porte, o Git oferece vários comandos administrativos para ajudar.
O comando git gc executa a “garbage collection” no repositório, removendo arquivos desnecessários do banco de dados e empacotando os arquivos restantes em um formato mais eficiente.
Normalmente, esse comando é executado em segundo plano, embora você possa executá-lo manualmente se quiser. Examinamos alguns exemplos disso em ch10-git-internals.asc.
O comando git fsck é usado para verificar se há problemas ou inconsistências no banco de dados interno.
Nós o usamos apenas uma vez, brevemente, em ch10-git-internals.asc para procurar objetos dangling.
O comando git reflog percorre um log das posições ocupadas pelos heads dos seus branches durante o trabalho para encontrar commits que você possa ter perdido ao reescrever históricos.
Abordamos esse comando principalmente em ch07-git-tools.asc, onde mostramos seu uso normal e como usar git log -g para ver as mesmas informações no formato de saída de git log.
Em ch10-git-internals.asc, também examinamos um exemplo prático de recuperação de um branch perdido dessa maneira.
O comando git filter-branch é usado para reescrever grandes quantidades de commits de acordo com determinados padrões, como remover um arquivo de todos eles ou filtrar todo o repositório até restar um único subdiretório para extrair um projeto.
Em ch07-git-tools.asc, explicamos o comando e exploramos várias opções, como --commit-filter, --subdirectory-filter e --tree-filter.
Em ch09-git-and-other-systems.asc, nós o usamos para corrigir repositórios externos importados.
Também encontramos no livro vários comandos de encanamento de baixo nível.
O primeiro deles é ls-remote, em ch06-github.asc, que usamos para examinar as referências brutas no servidor.
Usamos ls-files em ch07-git-tools.asc, ch07-git-tools.asc e ch07-git-tools.asc para ter uma visão mais bruta da área de preparação.
Também mencionamos rev-parse em ch07-git-tools.asc, que recebe praticamente qualquer string e a transforma no SHA-1 de um objeto.
No entanto, a maioria dos comandos de encanamento de baixo nível que abordamos está em ch10-git-internals.asc, que é, em linhas gerais, o foco daquele capítulo. Procuramos evitar seu uso na maior parte do restante do livro.