Comandos Git - Guia de referência Git em português

Comandos Git

Aprenda Git do básico ao avançado


Instalando e Configurando

Instalação


Instalar o Git no Windows é muito fácil. O projeto msysgit tem um dos procedimentos mais simples de instalação. Simplesmente baixe o arquivo exe do instalador a partir da página do GitHub e execute-o:

https://msysgit.github.com

Após concluir a instalação, você terá tanto uma versão command line (linha de comando, incluindo um cliente SSH que será útil depois) e uma GUI padrão.

Existem duas formas fáceis de se instalar Git em um Mac. A mais fácil delas é usar o instalador gráfico do Git, que você pode baixar da página do SourceForge:

https://sourceforge.net/projects/git-osx-installer/

A outra forma comum é instalar o Git via MacPorts (https://www.macports.org). Se você tem o MacPOrts instalado, instale o Git via

sudo port install git-core +svn +doc +bash_completion +gitweb

Se você quiser instalar o Git no Linux via um instalador binário, você pode fazê-lo com a ferramenta de gerenciamento de pacotes (packages) disponível na sua distribuição. Caso você esteja no Fedora, você pode usar o yum:

yum install git-core

Ou se você estiver em uma distribuição baseada no Debian, como o Ubuntu, use o apt-get:

apt-get install git

git config


A primeira coisa que você deve fazer quando instalar o Git é definir o seu nome de usuário e endereço de e-mail. Isso é importante porque todos os commits no Git utilizam essas informações, e está imutavelmente anexado nos commits que você realiza:

git config --global user.name "John Doe"
git config --global user.email johndoe@example.com

Relembrando, você só precisará fazer isso uma vez caso passe a opção --global, pois o Git sempre usará essa informação para qualquer coisa que você faça nesse sistema. Caso você queira sobrepor estas com um nome ou endereço de e-mail diferentes para projetos específicos, você pode executar o comando sem a opção --global quando estiver no próprio projeto.


Para ativar as cores nas respostas de comandos, você pode utilizar o seguinte comando:

Bem, nós iremos repassar esses comandos em um momento. Neste ponto, você tem um repositório Git com arquivos monitorados e um commit inicial.
git config --global color.ui true

git help


Se você precisar de ajuda ao usar Git, existem três maneiras de obter a ajuda para qualquer um dos comandos Git:

git help {comando}
git {comando} --help
man git- {comando}

Criando o projeto

git init


Você pode obter um projeto Git utilizando duas formas principais. A primeira faz uso de um projeto ou diretório existente e o importa para o Git. A segunda clona um repositório Git existente a partir de outro servidor.


Inicializando um Repositório em um Diretório Existente

Caso você esteja iniciando o monitoramento de um projeto existente com Git, você precisa ir para o diretório do projeto e digitar

git init

Isso cria um novo subdiretório chamado .git que contem todos os arquivos necessários de seu repositório — um esqueleto de repositório Git. Neste ponto, nada em seu projeto é monitorado.


Primeira versão

Caso você queira começar a controlar o versionamento dos arquivos existentes (diferente de um diretório vazio), você provavelmente deve começar a monitorar esses arquivos e fazer um commit inicial. Você pode realizar isso com poucos comandos

touch .gitignore
git add .gitignore
git commit -m "Versão inicial do projeto"

Bem, nós iremos repassar esses comandos em um momento. Neste ponto, você tem um repositório Git com arquivos monitorados e um commit inicial.

git clone


Você clona um repositório com git clone [url]. Por exemplo, caso você queria clonar a biblioteca Git do Ruby chamada Grit, você pode fazê-lo da seguinte forma:

git clone git://github.com/schacon/grit.git

Se você entrar no novo diretório grit, você verá todos os arquivos do projeto nele, pronto para serem editados ou utilizados. Caso você queira clonar o repositório em um diretório diferente de grit, é possível especificar esse diretório utilizando a opção abaixo:

git clone git://github.com/schacon/grit.git mygrit

Este comando faz exatamente a mesma coisa que o anterior, mas o diretório alvo será chamado mygrit.


Básico

git add


Quando um repositório é inicialmente clonado, todos os seus arquivos estarão monitorados e inalterados porque você simplesmente os obteve e ainda não os editou. Conforme você edita esses arquivos, o Git passa a vê-los como modificados, porque você os alterou desde seu último commit. Você seleciona esses arquivos modificados e então faz o commit de todas as alterações selecionadas e o ciclo se repete.

Monitorando Novos Arquivos

Para passar a monitorar um novo arquivo, use o comando git add. Para monitorar o arquivo README, você pode rodar isso:

git add README

Se você rodar o comando git status, você pode ver que o seu arquivo README agora está sendo monitorado. Os arquivos monitorados serão os que faram parte do commit.

git status


A principal ferramenta utilizada para determinar quais arquivos estão em quais estados é o comando:

git status

O comando lhe mostra em qual branch você se encontra. Vamos dizer que você adicione um novo arquivo em seu projeto, um simples arquivo README. Caso o arquivo não exista e você execute git status, você verá o arquivo não monitorado dessa forma:

# On branch master
# Untracked files:
# (use "git add {file}..." to include in what will be committed)
#
# README
nothing added to commit but untracked files present (use "git add" to track)

Você pode ver que o seu novo arquivo README não está sendo monitorado, pois está listado sob o cabeçalho "Untracked files" na saída do comando status. Não monitorado significa basicamente que o Git está vendo um arquivo que não existia na última captura (commit); o Git não vai incluí-lo nas suas capturas de commit até que você o diga explicitamente que assim o faça. Ele faz isso para que você não inclua acidentalmente arquivos binários gerados, ou outros arquivos que você não têm a intenção de incluir. Digamos, que você queira incluir o arquivo README, portanto vamos começar a monitorar este arquivo.

git diff


Se o comando git status for muito vago — você quer saber exatamente o que você alterou, não apenas quais arquivos foram alterados — você pode utilizar o comando.

git diff

Apesar do comando git status responder essas duas perguntas de maneira geral, o git diff mostra as linhas exatas que foram adicionadas e removidas — o patch, por assim dizer.
Se você quer ver o que selecionou que irá no seu próximo commit, pode utilizar:

git diff --cached

git commit


Armazena o conteúdo atual do índice em um novo commit, juntamente com uma mensagem de registro do usuário que descreve as mudanças.
Se usa o commit depois de já ter feito o git add, para fazer o commit:

git commit -m "Mensagem"

Para commitar também os arquivos versionados mesmo não estando no Stage basta adicionar o parâmetro -a

git commit -a -m "Mensagem"

Refazendo commit quando esquecer de adicionar um arquivo no Stage:

git commit -m "Mensagem" --amend

O amend é destrutivo e só deve ser utilizado antes do commit ter sido enviado ao servidor remoto.

git reset


Em qualquer fase, você pode querer desfazer alguma coisa. Aqui, veremos algumas ferramentas básicas para desfazer modificações que você fez. Cuidado, porque você não pode desfazer algumas dessas mudanças. Essa é uma das poucas áreas no Git onde você pode perder algum trabalho se fizer errado.
Para voltar ao último commit:

git reset --hard HEAD~1

Para voltar ao último commit e mantém os últimos arquivos no Stage:

git reset --soft HEAD~1

Volta para o commit com a hash XXXXXXXXXXX:

git reset --hard XXXXXXXXXXX
Recuperando commit apagado pelo git reset

Para visualizar os hashs

git reflog

E para aplicar:

git merge {hash}

git rm


Para remover um arquivo do Git, você tem que removê-lo dos arquivos que estão sendo monitorados (mais precisamente, removê-lo da sua área de seleção) e então fazer o commit. O comando git rm faz isso e também remove o arquivo do seu diretório para você não ver ele como arquivo não monitorado (untracked file) na próxima vez.

git rm -f {arquivo}

Se você modificou o arquivo e já o adicionou na área de seleção, você deve forçar a remoção com a opção -f. Essa é uma funcionalidade de segurança para prevenir remoções acidentais de dados que ainda não foram gravados em um snapshot e não podem ser recuperados do Git.

git mv


Diferente de muitos sistemas VCS, o Git não monitora explicitamente arquivos movidos.
É um pouco confuso que o Git tenha um comando mv. Se você quiser renomear um arquivo no Git, você pode fazer isso com

git mv arquivo_origem arquivo_destino

e funciona. De fato, se você fizer algo desse tipo e consultar o status, você verá que o Git considera que o arquivo foi renomeado.

No entanto, isso é equivalente a rodar algo como:

mv README.txt README
git rm README.txt
git add README

O Git descobre que o arquivo foi renomeado implicitamente, então ele não se importa se você renomeou por este caminho ou com o comando mv. A única diferença real é que o comando mv é mais conveniente, executa três passos de uma vez. O mais importante, você pode usar qualquer ferramenta para renomear um arquivo, e usar add/rm depois, antes de consolidar com o commit.


Branch e Merge

git branch


Um branch no Git é simplesmente um leve ponteiro móvel para um dos commits. O nome do branch padrão no Git é master. Como você inicialmente fez commits, você tem um branch principal (master branch) que aponta para o último commit que você fez. Cada vez que você faz um commit ele avança automaticamente.
O que acontece se você criar um novo branch? Bem, isso cria um novo ponteiro para que você possa se mover. Vamos dizer que você crie um novo branch chamado testing. Você faz isso com o comando git branch:

git branch testing

Isso cria um novo ponteiro para o mesmo commit em que você está no momento.
Para mudar para um branch existente, você executa o comando git checkout. Vamos mudar para o novo branch testing:

git checkout testing

Isto move o HEAD para apontar para o branch testing.

git checkout


Com o git checkout você pode mudar de branch, caso a branch ainda não exista você poderá passar o parâmetro -b para criar.

git checkout -b {nome_da_branch}

A partir do Git 2.23, o comando git switch foi introduzido como alternativa mais intuitiva para mudar de branch:

git switch {nome_da_branch}
git switch -c {nome_da_nova_branch}

O git checkout continua funcionando, mas o git switch é recomendado por ser mais claro na intenção.

git merge


Suponha que você decidiu que o trabalho na tarefa #53 está completo e pronto para ser feito o merge no branch master. Para fazer isso, você fará o merge do seu branch iss53, bem como o merge do branch hotfix de antes. Tudo que você tem a fazer é executar o checkout do branch para onde deseja fazer o merge e então rodar o comando git merge:

git checkout master
git merge iss53

git mergetool


Se você quer usar uma ferramenta gráfica para resolver esses problemas, você pode executar o seguinte comando que abre uma ferramenta visual de merge adequada e percorre os conflitos.

git mergetool
Arquivos Temporários

git mergetool cria * .orig arquivos de backup ao resolver fusões. Estes são seguros para remover uma vez que um arquivo foi fundida e sua git mergetool sessão foi concluída.

git log


Depois que você tiver criado vários commits, ou se clonou um repositório com um histórico de commits existente, você provavelmente vai querer ver o que aconteceu. A ferramente mais básica e poderosa para fazer isso é o comando:

git log

git stash


Muitas vezes, quando você está trabalhando em uma parte do seu projeto, as coisas estão em um estado confuso e você quer mudar de branch por um tempo para trabalhar em outra coisa. O problema é, você não quer fazer o commit de um trabalho incompleto somente para voltar a ele mais tarde. A resposta para esse problema é o comando git stash.
Você quer mudar de branch, mas não quer fazer o commit do que você ainda está trabalhando; você irá fazer o stash das modificações. Para fazer um novo stash na sua pilha, execute:

git stash

Seu diretório de trabalho estará limpo.
Neste momento, você pode facilmente mudar de branch e trabalhar em outra coisa; suas alterações estão armazenadas na sua pilha. Para ver as stashes que você guardou, você pode usar

git stash list

Você pode aplicar aquele que acabou de fazer o stash com o comando mostrado na saída de ajuda do comando stash original: git stash apply. Se você quer aplicar um dos stashes mais antigos, você pode especificá-lo, assim: git stash apply stash@{2}. Se você não especificar um stash, Git assume que é o stash mais recente e tenta aplicá-lo.

git tag


Git tem a habilidade de criar tags em pontos específicos na história do código como pontos importantes. Geralmente as pessoas usam esta funcionalidade para marcar pontos de release (v1.0, e por aí vai). Nesta seção, você aprenderá como listar as tags disponíveis, como criar novas tags, e quais são os tipos diferentes de tags.
Para listar as tags execute:

git tag

Para criar uma tag basta executar o seguinte comando, caso não queira criar a tag anotada, somente retire os parâmetros -a e -m.

git tag -a v1.4 -m 'my version 1.4'

Compartilhar e Atualizar Projetos

git fetch


Para pegar dados dos seus projetos remotos, você pode executar:

git fetch origin

Esse comando vai até o projeto remoto e pega todos os dados que você ainda não tem. Depois de fazer isso, você deve ter referências para todos os branches desse remoto, onde você pode fazer o merge ou inspecionar a qualquer momento.

git pull


Incorpora as alterações de um repositório remoto no branch atual. Em seu modo padrão, git pull é uma abreviação para git fetch seguido de git merge FETCH_HEAD. Por exemplo, se eu estiver em uma branch chamada develop e quiser atualizar caso haja atualizações remotamente:

git pull origin develop

git push


O git push é o comando em que você transfere commits a partir do seu repositório local para um repositório remoto. É a contrapartida do git fetch, que busca importações e comprometem as agências locais, utilizando o git push as exportações comprometem as filiais remotas. Para fazer isso, você executa git push [nome_do_repositório_remoto] [nome_da_sua_branch_local], que vai tentar fazer que o [nome_do_repositório_remoto] receba a sua branch [nome_da_sua_branch_local] contendo todos seus commits com alterações. Por exemplo:

git push origin develop

git remote


Para ver quais servidores remotos você configurou, execute o comando git remote. Ele lista os nomes abreviados de cada repositório remoto que você configurou. Para ver também as URLs que o Git armazenou para leitura e escrita, adicione -v:

git remote -v

Para adicionar um novo repositório remoto com um nome abreviado que você pode referenciar facilmente:

git remote add {apelido} {url}

Para renomear a referência de um repositório remoto:

git remote rename {nome_atual} {novo_nome}

Para remover uma referência de repositório remoto:

git remote remove {nome}

Para ver informações detalhadas sobre um repositório remoto específico:

git remote show {nome}

git submodule


Os submódulos permitem que você inclua um repositório Git como um subdiretório de outro repositório Git. Isso é útil quando você precisa incorporar bibliotecas externas ou projetos separados dentro do seu projeto principal.

Para adicionar um submódulo ao seu projeto:

git submodule add {url} {caminho}

Ao clonar um repositório que contém submódulos, você precisa inicializá-los e atualizá-los:

git submodule init
git submodule update

Ou você pode clonar recursivamente, o que faz tudo em um só passo:

git clone --recurse-submodules {url}

Para atualizar todos os submódulos para as últimas versões remotas:

git submodule update --remote

Inspeção e Comparação

git show


O comando git show exibe informações sobre objetos do Git (commits, tags, árvores, blobs). Para ver os detalhes de um commit específico, incluindo o diff das alterações:

git show {hash_do_commit}

Para ver o conteúdo de um arquivo em um commit específico:

git show {hash}:{caminho/do/arquivo}

Para exibir as informações de uma tag anotada:

git show v1.0

Sem argumentos, exibe os detalhes do último commit:

git show

git log


Além do uso básico, o git log oferece várias opções para personalizar a visualização do histórico. Para ver um resumo compacto com uma linha por commit:

git log --oneline

Para exibir um gráfico das branches e merges:

git log --oneline --graph --all

Para filtrar commits por autor:

git log --author="Nome"

Para filtrar por data:

git log --since="2024-01-01" --until="2024-12-31"

Para ver quais arquivos foram alterados em cada commit:

git log --stat

Para buscar commits cuja mensagem contenha um texto específico:

git log --grep="texto"

git diff


O git diff pode ser utilizado de várias formas avançadas. Para comparar dois branches:

git diff {branch1}..{branch2}

Para comparar dois commits específicos:

git diff {hash1} {hash2}

Para ver apenas os nomes dos arquivos alterados:

git diff --name-only

Para ver um resumo estatístico das alterações:

git diff --stat

Para comparar o stage (área de seleção) com o último commit:

git diff --staged

git shortlog


O git shortlog resume a saída do git log, agrupando os commits por autor. É útil para gerar changelogs ou ver quem contribuiu com o quê:

git shortlog

Para ver apenas a contagem de commits por autor, ordenado pela quantidade:

git shortlog -sn

Para incluir todos os branches:

git shortlog -sn --all

git describe


O git describe gera um nome legível para um commit com base na tag anotada mais próxima. Isso é muito útil para identificar versões de builds:

git describe

O resultado será algo como v1.0-3-g7a8b9c0, significando 3 commits após a tag v1.0, com o hash abreviado g7a8b9c0.

Para usar tags leves (não anotadas) também:

git describe --tags

Para descrever um commit específico:

git describe {hash_do_commit}

Pacotes

git apply


O comando git apply aplica um patch ao diretório de trabalho. Diferente de git am, ele não cria um commit automaticamente. Para aplicar um patch:

git apply {arquivo.patch}

Para verificar se um patch pode ser aplicado sem problemas antes de realmente aplicá-lo:

git apply --check {arquivo.patch}

Para ver as estatísticas do que o patch modificaria:

git apply --stat {arquivo.patch}

git cherry-pick


O git cherry-pick permite aplicar as alterações de um commit específico de outro branch no branch atual, criando um novo commit:

git cherry-pick {hash_do_commit}

Para aplicar vários commits de uma vez:

git cherry-pick {hash1} {hash2} {hash3}

Para aplicar as alterações sem criar o commit automaticamente:

git cherry-pick --no-commit {hash_do_commit}

Se ocorrer um conflito durante o cherry-pick, resolva o conflito e continue com:

git cherry-pick --continue

git diff


O git diff pode ser utilizado para gerar arquivos de patch que podem ser compartilhados e aplicados em outros repositórios. Para gerar um patch e salvá-lo em um arquivo:

git diff > alteracoes.patch

Para gerar um patch entre dois commits:

git diff {hash1} {hash2} > alteracoes.patch

Para gerar um patch apenas dos arquivos no stage:

git diff --cached > staged.patch

git rebase


O git rebase reaplica seus commits em cima de outro branch, criando um histórico linear. É uma alternativa ao merge. Para fazer rebase do seu branch atual sobre o master:

git rebase master

Para rebase interativo, que permite editar, reordenar, combinar ou excluir commits:

git rebase -i HEAD~3

Se ocorrer um conflito durante o rebase, resolva-o e continue:

git rebase --continue

Para cancelar o rebase e voltar ao estado anterior:

git rebase --abort

Atenção: nunca faça rebase de commits que já foram enviados para um repositório público compartilhado.

git revert


O git revert cria um novo commit que desfaz as alterações de um commit anterior. Diferente do git reset, ele é seguro para uso em branches compartilhados pois não reescreve o histórico:

git revert {hash_do_commit}

Para reverter sem criar o commit automaticamente (útil para reverter vários commits):

git revert --no-commit {hash_do_commit}

Para reverter um merge commit, especifique o parent number:

git revert -m 1 {hash_do_merge}

Debugando

git bisect


O git bisect usa busca binária para encontrar o commit que introduziu um bug. Inicie o processo de bisect:

git bisect start

Marque o commit atual como ruim (contém o bug):

git bisect bad

Marque um commit que você sabe que estava funcionando como bom:

git bisect good {hash_do_commit}

O Git vai fazer checkout do commit do meio e você testa. Se o bug existir, marque como bad, caso contrário como good. Repita até encontrar o commit exato. Ao finalizar:

git bisect reset

git blame


O git blame mostra, para cada linha de um arquivo, qual commit e autor a modificou pela última vez. É útil para rastrear a origem de uma alteração:

git blame {arquivo}

Para ver o blame de um intervalo específico de linhas:

git blame -L 10,20 {arquivo}

Para ignorar alterações de espaço em branco:

git blame -w {arquivo}

git grep


O git grep pesquisa por padrões de texto nos arquivos monitorados pelo Git. É mais rápido que o grep padrão por pesquisar apenas nos arquivos versionados:

git grep "texto_a_pesquisar"

Para mostrar o número da linha onde o texto foi encontrado:

git grep -n "texto_a_pesquisar"

Para contar o número de ocorrências por arquivo:

git grep -c "texto_a_pesquisar"

Para pesquisar em um commit ou branch específico:

git grep "texto_a_pesquisar" {branch_ou_hash}

Email

git am


O git am aplica patches recebidos por email que foram gerados com git format-patch. Ele cria commits automaticamente preservando a autoria e a mensagem originais:

git am {arquivo.patch}

Para aplicar todos os patches de um diretório de mailbox:

git am *.patch

Se ocorrer um conflito, resolva-o e continue:

git am --continue

Para pular o patch problemático:

git am --skip

Para abortar a operação inteira:

git am --abort

git apply


No contexto de email, o git apply é usado para aplicar patches gerados por git diff (em vez de git format-patch). Ele modifica os arquivos mas não cria commits:

git apply {arquivo.patch}

A diferença entre git apply e git am é que o git apply não preserva as informações de autoria e não cria commits automaticamente.

git format-patch


O git format-patch gera patches no formato de email, prontos para serem enviados. Para gerar patches dos últimos N commits:

git format-patch -3

Para gerar patches de todos os commits de um branch que não estão no master:

git format-patch master

Para gerar todos os patches em um único arquivo:

git format-patch master --stdout > todas_alteracoes.patch

git send-email


O git send-email envia patches gerados pelo git format-patch diretamente por email via SMTP. É comumente usado em projetos que aceitam contribuições por email, como o kernel Linux:

git send-email *.patch

Para enviar para um destinatário específico:

git send-email --to=email@exemplo.com *.patch

Antes de usar, configure o SMTP nas configurações do Git:

git config --global sendemail.smtpserver smtp.exemplo.com
git config --global sendemail.smtpserverport 587

git request-pull


O git request-pull gera um resumo das alterações entre dois commits, formatado para ser enviado a um mantenedor de projeto, solicitando que ele puxe as suas alterações:

git request-pull {commit_inicial} {url_do_repositorio} {branch}

Exemplo prático:

git request-pull v1.0 https://github.com/user/repo master

O resultado inclui a lista de commits, os arquivos alterados e a URL de onde o mantenedor pode fazer o pull.


Sistemas Externos

git svn


O git svn permite usar o Git como cliente para um repositório Subversion (SVN). Para clonar um repositório SVN:

git svn clone {url_svn}

Para clonar com o layout padrão do SVN (trunk, branches, tags):

git svn clone -s {url_svn}

Para atualizar seu repositório local com as últimas alterações do SVN:

git svn rebase

Para enviar seus commits locais de volta para o SVN:

git svn dcommit

git fast-import


O git fast-import é uma ferramenta de alto desempenho para importar dados de outros sistemas de controle de versão para o Git. Ele lê um fluxo de dados formatado e cria objetos Git rapidamente:

git fast-import < dados_exportados.txt

O formato de entrada é específico e geralmente gerado por scripts de migração. Cada entrada define commits, blobs e referências no formato que o Git espera.

Após a importação, verifique o resultado com:

git log --oneline --all

Administração

git clean


O git clean remove arquivos não monitorados do diretório de trabalho. Para ver quais arquivos seriam removidos sem realmente removê-los:

git clean -n

Para remover os arquivos não monitorados (requer o parâmetro -f por segurança):

git clean -f

Para remover também diretórios não monitorados:

git clean -fd

Para remover inclusive arquivos ignorados pelo .gitignore:

git clean -fdx

git gc


O git gc (garbage collection) otimiza o repositório local, compactando objetos soltos e removendo objetos que não são mais acessíveis:

git gc

Para uma limpeza mais agressiva:

git gc --aggressive

O Git executa o gc automaticamente de tempos em tempos, mas pode ser útil executá-lo manualmente em repositórios muito grandes.

git fsck


O git fsck (file system check) verifica a integridade e conectividade dos objetos no banco de dados do Git:

git fsck

Para ver também objetos inalcançáveis (dangling objects):

git fsck --unreachable

É útil para diagnosticar problemas de corrupção no repositório ou para encontrar objetos perdidos.

git reflog


O git reflog registra todas as atualizações do HEAD e das referências de branches locais. É extremamente útil para recuperar commits "perdidos" após um reset ou rebase:

git reflog

Para ver o reflog de um branch específico:

git reflog show {nome_do_branch}

Para recuperar um commit usando o reflog:

git checkout HEAD@{2}

O reflog é mantido localmente e por padrão expira após 90 dias.

git filter-branch


O git filter-branch reescreve o histórico de commits aplicando filtros. Atenção: este comando é destrutivo e foi substituído pelo git filter-repo (ferramenta externa recomendada).

Para remover um arquivo de todo o histórico:

git filter-branch --tree-filter 'rm -f {arquivo}' HEAD

Para alterar o email do autor em todos os commits:

git filter-branch --env-filter '
if [ "$GIT_AUTHOR_EMAIL" = "antigo@email.com" ]; then
  export GIT_AUTHOR_EMAIL="novo@email.com"
fi' HEAD

A alternativa moderna recomendada é o git filter-repo:

git filter-repo --path {arquivo} --invert-paths

git instaweb


O git instaweb inicia instantaneamente um servidor web para navegar pelo repositório usando o GitWeb:

git instaweb

Para especificar o servidor HTTP a ser utilizado:

git instaweb --httpd=webrick

Para parar o servidor:

git instaweb --stop

git archive


O git archive cria um arquivo compactado (tar ou zip) do conteúdo de uma árvore Git, sem incluir os metadados do Git:

git archive --format=tar HEAD | gzip > projeto.tar.gz

Para criar um arquivo zip:

git archive --format=zip HEAD > projeto.zip

Para exportar apenas um subdiretório:

git archive HEAD {caminho/do/diretorio} > subdir.tar

Para exportar uma tag ou branch específica:

git archive --format=zip v1.0 > release-v1.0.zip

Servidor

git daemon


O git daemon inicia um servidor Git simples que disponibiliza repositórios via o protocolo git:// (porta 9418). É útil para compartilhamento rápido em redes locais:

git daemon --reuseaddr --base-path=/caminho/dos/repos /caminho/dos/repos

Para permitir push anônimo (use com cautela):

git daemon --reuseaddr --enable=receive-pack --base-path=/caminho/dos/repos

No repositório que deseja exportar, crie o arquivo que autoriza a exportação:

touch .git/git-daemon-export-ok

git update-server-info


O git update-server-info atualiza os arquivos auxiliares necessários para servir um repositório Git via HTTP (protocolo "dumb"). Execute após cada push em repositórios servidos por servidores web estáticos:

git update-server-info

Este comando atualiza os arquivos info/refs e objects/info/packs, que são necessários para que clientes possam descobrir as referências e objetos disponíveis.

Geralmente, este comando é configurado como um hook post-update para ser executado automaticamente.


Canalização de Código

git cat-file


O git cat-file exibe o conteúdo, tipo ou tamanho de objetos do Git (blobs, trees, commits, tags). Para ver o tipo de um objeto:

git cat-file -t {hash}

Para ver o conteúdo de um objeto:

git cat-file -p {hash}

Para ver o tamanho de um objeto:

git cat-file -s {hash}

git commit-tree


O git commit-tree cria um novo objeto de commit a partir de um objeto tree. É o comando de baixo nível que o git commit usa internamente:

echo "mensagem" | git commit-tree {hash_da_tree}

Para criar um commit com um parent específico:

echo "mensagem" | git commit-tree {hash_da_tree} -p {hash_do_parent}

git count-objects


O git count-objects conta o número de objetos soltos e o espaço em disco que eles ocupam:

git count-objects

Para uma saída mais detalhada incluindo objetos empacotados:

git count-objects -v

git diff-index


O git diff-index compara uma árvore (tree) com o índice (staging area) ou com o diretório de trabalho. É o comando de baixo nível usado pelo git diff:

git diff-index HEAD

Para comparar apenas o índice (sem verificar o diretório de trabalho):

git diff-index --cached HEAD

git for-each-ref


O git for-each-ref exibe informações sobre cada referência no repositório. É útil para scripts e automação. Para listar todos os branches com seus últimos commits:

git for-each-ref --format='%(refname:short) %(objectname:short) %(subject)' refs/heads/

Para listar tags ordenadas por data:

git for-each-ref --sort=-creatordate --format='%(refname:short)' refs/tags/

git hash-object


O git hash-object calcula o hash SHA de um objeto e opcionalmente o armazena no banco de dados do Git. Para calcular o hash de um arquivo:

git hash-object {arquivo}

Para calcular o hash e armazenar o objeto no banco de dados:

git hash-object -w {arquivo}

Para calcular o hash de uma string:

echo "conteudo" | git hash-object --stdin

git merge-base


O git merge-base encontra o melhor ancestral comum entre dois commits, que é o ponto de partida para um merge de três vias:

git merge-base {branch1} {branch2}

Para verificar se um commit é ancestral de outro:

git merge-base --is-ancestor {commit1} {commit2}

git read-tree


O git read-tree lê informações de uma árvore (tree) para o índice (staging area). É o comando de baixo nível usado por git checkout e git merge:

git read-tree {hash_da_tree}

Para fazer um merge de três vias no índice:

git read-tree -m {base} {branch1} {branch2}

git rev-list


O git rev-list lista objetos de commit em ordem cronológica reversa. É o comando de baixo nível que alimenta o git log:

git rev-list HEAD

Para contar o número total de commits:

git rev-list --count HEAD

Para listar commits que estão em um branch mas não em outro:

git rev-list {branch1} ^{branch2}

git rev-parse


O git rev-parse traduz nomes de referências em hashes SHA. É amplamente utilizado em scripts:

git rev-parse HEAD

Para obter o diretório raiz do repositório:

git rev-parse --show-toplevel

Para verificar se está dentro de um repositório Git:

git rev-parse --is-inside-work-tree

Para obter o nome abreviado do branch atual:

git rev-parse --abbrev-ref HEAD

git show-ref


O git show-ref lista referências (branches e tags) no repositório local junto com seus hashes:

git show-ref

Para listar apenas tags:

git show-ref --tags

Para verificar se uma referência existe:

git show-ref --verify refs/heads/{branch}

git symbolic-ref


O git symbolic-ref lê ou modifica referências simbólicas (como HEAD). Para ver para qual branch o HEAD aponta:

git symbolic-ref HEAD

Para obter apenas o nome curto do branch:

git symbolic-ref --short HEAD

Para alterar o HEAD para apontar para outro branch:

git symbolic-ref HEAD refs/heads/{branch}

git update-index


O git update-index modifica o índice (staging area) diretamente. Para marcar um arquivo como "assume unchanged" (útil para ignorar alterações locais de configuração):

git update-index --assume-unchanged {arquivo}

Para reverter e voltar a monitorar as alterações:

git update-index --no-assume-unchanged {arquivo}

Para adicionar um arquivo ao índice manualmente:

git update-index --add {arquivo}

git update-ref


O git update-ref atualiza o hash armazenado em uma referência de forma segura. Para apontar um branch para um commit específico:

git update-ref refs/heads/{branch} {hash}

Para deletar uma referência:

git update-ref -d refs/heads/{branch}

git verify-pack


O git verify-pack verifica a validade de um arquivo de pacote Git (.pack). Para verificar um pacote e listar seu conteúdo:

git verify-pack -v .git/objects/pack/{arquivo}.idx

É útil para diagnosticar problemas com pacotes corrompidos ou para analisar quais objetos ocupam mais espaço no repositório.

git write-tree


O git write-tree cria um objeto tree a partir do conteúdo atual do índice (staging area). É o complemento do git read-tree e é usado internamente pelo git commit:

git write-tree

O comando retorna o hash SHA-1 da árvore criada, que pode ser usado com git commit-tree para criar um commit manualmente.