git status

O comando git status responde a uma única pergunta constante enquanto você trabalha: o que mudou desde meu último commit e o que está pronto para ser confirmado? É o comando que você executa mais do que qualquer outro — antes de preparar arquivos para o commit, antes de confirmar e sempre que você perde o controle da situação de um arquivo. Esta página explica os três estados em que um arquivo pode se encontrar, como ler a saída longa e a curta, e as opções que fazem o status funcionar bem em scripts.

O que o git status exibe

O git status mostra o estado de duas coisas: o diretório de trabalho (os arquivos em disco que você está editando) e a área de preparação (staging area), também chamada de index (o instantâneo que você está preparando para o próximo commit). Ele informa quais arquivos estão:

• Preparados (staged) — alterações adicionadas com git add e prontas para o próximo commit.
• Não preparados (modificados) — arquivos rastreados que você alterou, mas ainda não adicionou.
• Não rastreados (untracked) — novos arquivos que o Git nunca viu e não está acompanhando.

O que o git status não exibe é o histórico de commits. Ele não diz nada sobre commits anteriores, branches mescladas ou quem alterou o quê — para isso, use git log. Também não mostra o conteúdo das suas alterações; para ver as linhas exatas adicionadas e removidas, use git diff. Em resumo, o status resume o efeito de git add e git commit nos seus arquivos atuais.

Uso básico

O comando não recebe argumentos na sua forma mais comum:

git status

Em um repositório limpo, sem nada para fazer, o Git informa:

On branch master
nothing to commit, working tree clean

Lendo a saída longa

A saída padrão (também acessível com --long) é o formato detalhado e legível por humanos. Acompanhe um arquivo ao longo de seu ciclo de vida para ver cada seção aparecer.

Um arquivo completamente novo que o Git nunca viu é não rastreado (untracked):

On branch master

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)
	w3docs.txt

nothing added to commit but untracked files present (use "git add" to track)

Após git add w3docs.txt, o mesmo arquivo passa para Changes to be committed — ele está agora preparado (staged):

On branch master

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
	new file:   w3docs.txt

Após o git commit, a árvore de trabalho fica limpa novamente. Agora edite w3docs.txt e crie um segundo arquivo new.txt. Um arquivo rastreado que você alterar aparece em Changes not staged for commit, enquanto o arquivo completamente novo permanece em Untracked files:

On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
	modified:   w3docs.txt

Untracked files:
  (use "git add <file>..." to include in what will be committed)
	new.txt

no changes added to commit (use "git add" and/or "git commit -a")

Observe que as dicas entre parênteses são sugestões reais e executáveis: o Git indica como remover da área de preparação, descartar ou adicionar em cada etapa.

O formato curto

Depois de entender o significado de cada seção, o formato longo torna-se verboso. A flag -s (ou --short) condensa tudo em uma linha por arquivo:

git status -s

Para o estado acima (um arquivo rastreado modificado, um novo arquivo não rastreado) ele exibe:

 M w3docs.txt
?? new.txt

Cada entrada tem um código de status de duas colunas. A coluna da esquerda é a área de preparação (o index) e a coluna da direita é a árvore de trabalho:

Um espaço inicial significa "nenhuma alteração nessa coluna." Portanto, M significa modificado mas não preparado, M significa que a modificação está preparada e MM significa uma alteração preparada mais edições adicionais não preparadas no mesmo arquivo.

Adicione -b para também exibir o branch atual e suas informações de rastreamento:

git status -sb

## master
 M w3docs.txt
?? new.txt

Saída para scripts: --porcelain

Se você quiser ler o git status a partir de um script, não analise o formato curto ou longo — ambos podem mudar entre versões do Git e são afetados pela configuração do usuário. Use --porcelain. Ele garante um formato estável e legível por máquina:

git status --porcelain

 M w3docs.txt
?? new.txt

As colunas usam os mesmos códigos de dois caracteres do formato curto, mas o formato é contratualmente estável, tornando-o seguro para hooks, verificações de CI e prompts de shell. Combine com -z para encerrar cada entrada com um byte NUL em vez de uma nova linha, o que mantém inequívocos os nomes de arquivos que contêm espaços ou novas linhas.

Exibindo arquivos ignorados

Por padrão, o git status oculta arquivos correspondidos pelas regras do seu .gitignore — artefatos de build e binários como .pyc, .obj, .exe ou arquivos de log, caso contrário, suprimiriam as alterações reais. Para confirmar que um arquivo está sendo ignorado (em vez de simplesmente esquecido), adicione --ignored:

git status --ignored

Com um .gitignore contendo *.log e um debug.log em disco, uma seção extra aparece:

Ignored files:
  (use "git add -f <file>..." to include in what will be committed)
	debug.log

Essa é a maneira mais rápida de depurar uma regra de ignore que está correspondendo mais — ou menos — do que o esperado.

Opções comuns

Por que verificar o status frequentemente

É uma boa prática executar git status antes de cada git add e git commit. Uma verificação rápida evita erros comuns: confirmar um arquivo que você esqueceu de preparar, preparar acidentalmente um arquivo de depuração ou confirmar no branch errado. Como o status apenas lê o repositório e nunca altera nada, executá-lo é sempre seguro.

Depois de ler o status, os próximos passos naturais são inspecionar as alterações exatas com git diff, desfazer um erro de preparação com git reset ou, se ainda não começou, criar o repositório com git init.

Prática