ToolActToolAct

Referência de Comandos Git

Manual de referência completo de comandos Git, organizado por categoria para consulta rápida

Todos: 65 个命令

Comandos Básicos(13)

git init

Criar um novo repositório Git no diretório atual

git clone <url>

Clonar um repositório remoto para local

git clone --depth=1 <url>

Clone shallow, busca apenas o commit mais recente

git add <file>

Adicionar arquivo à área de staging

git add .

Adicionar todas as mudanças à área de staging

git commit -m "message"

Fazer commit das alterações preparadas

git commit --amend

Modificar o último commit

git status

Mostrar status atual do repositório

git diff

Mostrar mudanças não staged

git diff --staged

Mostrar mudanças staged

git config --list

Mostrar toda configuração

git config --global user.name "name"

Definir nome de usuário global

git config --global user.email "email"

Definir email global

Gerenciamento de Branch(14)

git branch

Listar todas as branches locais

git branch -a

Listar todas as branches (incluindo remotas)

git branch <name>

Criar uma nova branch

git branch -d <name>

Deletar uma branch

git branch -m <old> <new>

Renomear uma branch

git checkout <branch>

Mudar para uma branch

git checkout -b <branch>

Criar e mudar para nova branch

git switch <branch>

Mudar para uma branch (Git 2.23+)

git switch -c <branch>

Criar e mudar para nova branch (Git 2.23+)

git merge <branch>

Merge branch especificada na branch atual

git merge --no-ff <branch>

Merge com um merge commit

git rebase <branch>

Rebase branch atual na branch especificada

git rebase --continue

Continuar rebase após resolver conflitos

git cherry-pick <commit>

Aplicar commit específico na branch atual

Operações Remotas(10)

git remote -v

Mostrar detalhes do repositório remoto

git remote add <name> <url>

Adicionar um repositório remoto

git fetch <remote>

Buscar conteúdo mais recente do remoto

git fetch --all

Buscar atualizações de todos os remotos

git pull <remote> <branch>

Buscar e merge branch remota

git pull --rebase

Buscar e rebase

git push <remote> <branch>

Push para repositório remoto

git push -f

Forçar push (use com cuidado)

git push -u origin <branch>

Push e definir branch upstream

git push origin --delete <branch>

Deletar branch remota

Desfazer Mudanças(8)

git reset <file>

Unstage um arquivo

git reset --soft HEAD~1

Desfazer último commit, manter mudanças

git reset --mixed HEAD~1

Desfazer commit e staging, manter working directory

git reset --hard HEAD~1

Desfazer commit e descartar todas as mudanças

git revert <commit>

Desfazer um commit (cria novo commit)

git restore <file>

Restaurar arquivo do working directory (Git 2.23+)

git restore --staged <file>

Unstage arquivo (Git 2.23+)

git clean -fd

Remover arquivos e diretórios não rastreados

Gerenciamento de Tags(6)

git tag

Listar todas as tags

git tag <name>

Criar uma tag lightweight

git tag -a <name> -m "msg"

Criar uma tag annotated

git tag -d <name>

Deletar tag local

git push origin <tag>

Push tag para remoto

git push --tags

Push todas as tags para remoto

Ver Histórico(7)

git log

Mostrar histórico de commits

git log --oneline

Mostrar histórico de commits compacto

git log --oneline --graph --all

Mostrar histórico de todas as branches como graph

git show <commit>

Mostrar detalhes do commit

git blame <file>

Mostrar histórico de modificação para cada linha

git reflog

Mostrar todo histórico de operações

git bisect start

Iniciar binary search para commit problemático

Stash(7)

git stash

Stash mudanças atuais

git stash save "message"

Stash mudanças com mensagem

git stash list

Listar todos os stashes

git stash pop

Aplicar e drop o stash mais recente

git stash apply

Aplicar stash sem drop

git stash drop

Drop o stash mais recente

git stash clear

Remover todos os stashes

O que é Git?

Uma folha de referência Git é um guia rápido de comandos de controle de versão, organizado pela tarefa que você quer executar. Git é um sistema distribuído: cada clone contém o histórico do projeto, branches são ponteiros leves e commits registram como a base de código mudou ao longo do tempo. A referência ajuda quando você lembra o fluxo, mas não a sintaxe exata, como ver mudanças staged, criar branch, desfazer commit, guardar trabalho com stash, marcar uma release ou sincronizar com remoto. É uma referência, não substitui entender o estado do repositório. Comandos destrutivos como reset --hard, clean -fd, rebase e push forçado só devem ser copiados depois de revisar alterações não commitadas, branch atual e impacto remoto.

Guia de Uso

Referência Rápida

  1. Clique em qualquer cartão de comando para copiá-lo
  2. Use a caixa de busca para localizar comandos específicos rapidamente
  3. Clique nas tags de categoria para filtrar por tipo
  4. Passe o mouse sobre os comandos para ver descrições detalhadas

Recursos

Organizado por cenárioComandos agrupados por basic, branch, remote, undo, tags, history e stash para consulta fácil, sem precisar percorrer toda a lista.
Busca e filtrosCombine a caixa de busca e os botões de categoria para reduzir os resultados rapidamente, ideal quando você lembra apenas parte do comando ou da descrição.
Clique para copiarClique no cartão de comando para copiar e, em seguida, substitua nomes de branch, caminhos de arquivo ou hashes de commit conforme necessário.
Aviso de riscoComandos de undo, reset e force push exigem a confirmação do escopo de impacto para evitar excluir alterações locais por engano ou reescrever o histórico compartilhado.

Dicas Avançadas

  • Use git restore --staged para tirar arquivos do stage
  • Use git commit --amend para modificar o último commit
  • Use git stash para salvar temporariamente o progresso do trabalho
  • Use git revert para desfazer commits já enviados

Casos de uso

Encontrar a categoria de comando necessária no meio da tarefaPesquise ou filtre comandos Git por trabalho básico, branches, remotos, desfazer, tags, histórico e stash para que a sintaxe correta fique visível sem escanear um artigo longo ou reabrir uma aba de tutorial. Cada cartão já mostra a descrição curta ao lado do comando, o que é útil quando você lembra o fluxo, mas não as flags exatas, como precisar de --force-with-lease versus --force, ou querer saber a diferença entre git restore e git reset.
Copiar comandos com os placeholders intactosUse a cópia com um clique para comandos como git checkout -b <branch>, git push -u origin <branch>, git log --oneline --graph --all ou git restore --staged <file>, depois substitua os placeholders no seu terminal. Como a referência fica no navegador e nenhum dado de commit ou nome de branch é enviado a qualquer lugar, é seguro copiar junto com hashes reais, prefixos de branch internos ou nomes de funcionalidades em desenvolvimento que ainda não foram enviados.
Revisar comandos arriscados antes de usá-losA seção de desfazer reúne fluxos de trabalho de reset, clean, restore e force push para que a intenção destrutiva fique visível de relance. Antes de executar git reset --hard HEAD~3 ou git push --force, confira a branch atual com git status e o estado de rastreamento remoto com git rev-parse --abbrev-ref --symbolic-full-name @{u}, já que reescrever histórico compartilhado ainda não pode ser desfeito pelos colegas de equipe.
Salvar snippets de branch, tag e stash como modelosComandos como 'git switch -c feature/x', 'git tag -a v1.2 -m' e 'git stash push -m' se repetem entre projetos seguindo as convenções de branching ou release da equipe. Copie-os uma vez no documento de onboarding, runbook ou configuração de pre-commit hook da equipe, e revise sempre que o comportamento do Git mudar — por exemplo, quando um projeto exigir --force-with-lease em vez de --force simples em branches protegidas.
Usar comandos de histórico para ler o repositório, não reescrevê-loExecute 'git log --oneline --graph --all', 'git blame -L' e 'git diff <branch>...' para entender quem mudou o quê antes de abrir um rebase ou revert. Ler primeiro é mais barato do que recuperar de uma reescrita de histórico mal feita, especialmente em monorepos onde um rebase acidental entre branches de funcionalidade pode invalidar dezenas de pull requests em andamento.

Princípio técnico

O Git armazena cada estado do projeto como um grafo de objetos endereçável por conteúdo dentro de .git/objects, onde o endereço é um hash SHA-1 de 40 caracteres (SHA-256 é opcional desde o formato de objeto experimental do Git 2.29). Existem quatro tipos de objetos: blob armazena bytes brutos de arquivos, tree mapeia nomes para blobs e subárvores, commit aponta para uma tree além de commits pais e metadados do autor, e tag é um ponteiro assinado para qualquer um dos anteriores. Branches e tags sob refs/heads/, refs/remotes/ e refs/tags/ são apenas arquivos de texto contendo um SHA, e HEAD é uma referência simbólica que nomeia a branch atual.

Mudanças locais fluem por três áreas: o diretório de trabalho, o index (também chamado de staging area, armazenado em .git/index), e o banco de dados de objetos. git add registra hashes de blob no index, git commit congela o index em uma nova tree mais objeto de commit, e git checkout/switch atualiza o index e a working tree para um commit alvo. Merges se enquadram em duas categorias: fast-forward simplesmente avança o ponteiro da branch quando o alvo é um descendente direto, enquanto merges de três vias (estratégia recursiva ou ort) calculam um ancestral comum e constroem um merge commit com dois pais. git rebase reescreve o histórico reproduzindo commits um por um sobre uma nova base, produzindo novos SHAs.

A sincronização remota roda sobre o protocolo inteligente HTTPS, SSH, ou o protocolo depreciado git://, trocando arquivos pack gerados por compressão delta. Após um fetch, o Git armazena o snapshot sob refs/remotes/origin/* e o reflog sob .git/logs/ mantém um rastro de desfazer de 90 dias por padrão (gc.reflogExpire) para que mesmo reset --hard ou um rebase mal feito possam ser recuperados antes que a coleta de lixo poda objetos inalcançáveis.
  • Modelo de objetos: blob, tree, commit, tag — endereçáveis por conteúdo via SHA-1 (ou SHA-256 desde 2.29), armazenados avulsos em .git/objects/xx/ ou empacotados em .git/objects/pack/*.pack
  • Index/staging: .git/index é um arquivo binário mapeando caminho → hash do blob + informações de stat; git add o atualiza, git commit o congela em uma tree
  • Refs e HEAD: refs/heads/<branch>, refs/remotes/<remote>/<branch>, refs/tags/<tag> são arquivos simples contendo um SHA; HEAD é uma referência simbólica para a branch atual
  • Estratégias de merge: fast-forward quando o alvo é um descendente, caso contrário merge recursivo/ort de três vias usando a merge base; --no-ff força um merge commit
  • Reescrita de rebase: git rebase reproduz commits sobre uma nova base produzindo novos SHAs, quebrando o histórico compartilhado se enviado — por isso --force-with-lease é preferido a --force
  • Recuperação via reflog: .git/logs/HEAD e logs por referência retêm movimentos de ref por 90 dias (gc.reflogExpire); git reflog mais git reset restaura após operações destrutivas
  • Transporte: HTTPS inteligente, SSH ou git:// negociam arquivos pack via o protocolo upload-pack/receive-pack; clones rasos usam --depth para limitar o histórico

Exemplos

Criar e mudar para um novo branch

git checkout -b feature/login  # Cria e muda para um novo branch

Desfazer alterações no diretório de trabalho

git restore filename  # Restaura o arquivo para o último estado commitado

Ver histórico de commits

git log --oneline --graph --all  # Exibe graficamente o histórico de todos os branches

Perguntas frequentes

Como desfaço meu commit mais recente?

git reset --soft HEAD~1 mantém suas alterações no staging para você commitar de novo; git reset --mixed HEAD~1 mantém na working tree mas fora do staging; git reset --hard HEAD~1 descarta tudo. Se o commit já foi enviado, use git revert HEAD em vez disso, que cria um novo commit que desfaz a mudança sem reescrever o histórico.

Qual a diferença entre git pull e git fetch?

git fetch só baixa commits do remoto para suas refs locais — nunca mexe na sua branch de trabalho. git pull equivale a git fetch seguido de git merge (ou git rebase se --rebase estiver definido). Use fetch quando quiser inspecionar as mudanças do upstream antes de integrá-las.

Como descarto alterações locais em um arquivo?

git restore <arquivo> descarta edições não commitadas na working tree; git restore --staged <arquivo> tira o arquivo do staging sem perder o conteúdo; git checkout HEAD -- <arquivo> restaura a versão do último commit. Para arquivos não rastreados, use git clean -f ou -fd para também remover diretórios.

Quando devo usar rebase em vez de merge?

Rebase quando você quer um histórico linear numa branch privada de feature antes de fazer merge de volta. Merge ao integrar uma branch compartilhada onde preservar o histórico real do desenvolvimento importa. Nunca faça rebase em commits que já foram enviados para uma branch compartilhada, a menos que todos concordem — isso reescreve os SHAs e quebra os clones dos outros.

Como vejo o que está prestes a ser enviado?

git log @{u}.. mostra os commits da sua branch que não estão no upstream. git diff @{u} mostra o diff combinado. git status, comparado com origin (depois de um fetch), mostra a contagem de commits à frente/atrás.

Como recupero uma branch deletada ou um commit perdido?

git reflog lista todas as posições onde o HEAD esteve; encontre o SHA do commit que você perdeu e rode git checkout <sha> ou git branch <nome> <sha>. Entradas do reflog duram cerca de 90 dias por padrão antes da coleta de lixo, então faça isso logo depois do erro.

Qual o jeito mais seguro de emendar um commit?

git commit --amend permite editar a mensagem do commit mais recente ou adicionar arquivos esquecidos. Ele reescreve o SHA, então faça isso só em commits locais que ainda não foram enviados. Se precisar emendar um commit já enviado, use push com --force-with-lease (não --force) para evitar atropelar atualizações dos colegas.