Git
Português (Brasil) ▾Topics ▾Latest version ▾ git-status last updated in 2.45.0

NOME

git-status - Exibe o a condição da árvore de trabalho

RESUMO

git status [<opções>] [--] [<pathspec>…​]

DESCRIÇÃO

Exibe os caminhos que têm diferenças entre o arquivo do índice e o commit atual no HEAD, os caminhos que têm diferenças entre a árvore de trabalho e o arquivo do índice, os caminhos na árvore de trabalho que não são rastreados pelo Git (e não foram ignorados pelo gitignore[5]). O primeiro é o que você confirmaria executando o comando git commit; o segundo e o terceiro são os que você pode confirmar, executando o comando git add antes de executar o comando git commit.

OPÇÕES

-s
--short

Dar a saída em um formato curto.

-b
--branch

Exibe o ramo e a informação de rastreio quando estiver em formato curto.

--show-stash

Exibe a quantidade das entradas que estão atualmente acumuladas.

--porcelain[=<versão>]

Forneça a saída num formato fácil de analisar para scripts. Isso é semelhante à saída curta, mas permanecerá estável em todas as versões do Git e independentemente da configuração do usuário. Veja abaixo para mais detalhes.

O parâmetro version é usado para especificar a versão do formato. Isso é opcional e a predefiniçãoé o formato da versão original v1.

--long

Gere um formato longo na saída. Esta é a predefinição.

-v
--verbose

Além dos nomes dos arquivos que foram alterados, exiba também as alterações textuais que são preparadas para o commit (ou seja, como a saída do git diff --cached). Caso a opção -v seja utilizada duas vezes, também exiba as alterações na árvore de trabalho que ainda não foram preparadas (ou seja, como a saída do comando git diff).

-u[<modo>]
--untracked-files[=<modo>]

Exibe arquivos sem rastreamento.

O parâmetro mode é usado para especificar o tratamento de arquivos não rastreados. É opcional: a predefinição é all e, se especificado, deve estar vinculado à opção (-uno, mas não -u no por exemplo).

As opções disponíveis são:

  • no - Não mostra os arquivos não rastreados.

  • normal - Exibe todos os arquivo e diretórios não rastreados.

  • all - Exibe todos os arquivos individualmente nos diretórios não rastreados.

When -u option is not used, untracked files and directories are shown (i.e. the same as specifying normal), to help you avoid forgetting to add newly created files. Because it takes extra work to find untracked files in the filesystem, this mode may take some time in a large working tree. Consider enabling untracked cache and split index if supported (see git update-index --untracked-cache and git update-index --split-index), Otherwise you can use no to have git status return more quickly without showing untracked files. All usual spellings for Boolean value true are taken as normal and false as no.

A predefinição pode ser alterada utilizando a variável de configuração status.showUntrackedFiles documentada em git-config[1].

--ignore-submodules[=<quando>]

Ignorar alterações em submódulos ao procurar alterações. <quando> pode ser none, untracked, dirty ou all, que é o padrão. O uso de none considerará o submódulo modificado quando ele contiver arquivos não rastreados ou modificados ou quando seu HEAD for diferente do commit registrado no superprojeto e pode ser usado para substituir qualquer configuração da opção ignore do comando git-config[1] ou gitmodules[5]. Quando untracked (não rastreado) é usado, os submódulos não são considerados sujos quando contêm apenas conteúdo não rastreado (mas ainda são verificados quanto a conteúdo modificado). O uso de dirty ignora todas as alterações na árvore de trabalho dos submódulos; somente as alterações nos commits armazenados no superprojeto são mostradas (este era o comportamento antes da versão 1.7.0). O uso de all oculta todas as alterações nos submódulos (e suprime a saída dos resumos dos submódulos quando a opção de configuração status.submoduleSummary é definida).

--ignored[=<modo>]

Exiba os arquivos ignorados também.

O parâmetro mode é usado para especificar o tratamento de arquivos ignorados. É opcional: o padrão é traditional.

As opções disponíveis são:

  • traditional - Exibe os arquivos e diretórios ignorados, a menos que --untracked-files=all é especificado, neste caso os arquivos individuais nos diretórios que foram ignorados são exibidos.

  • no - Não exibe os arquivos ignorados.

  • matching - Exibe os arquivos e diretórios ignorados que correspondem a um ignora o padrão.

Quando o modo matching é utilizado, os caminhos que coincidam explicitamente a um padrão ignorado são exibidos. Caso um diretório coincidir com um padrão a ser ignorado, ele será exibido, mas não os caminhos existentes no diretório ignorado. Caso um diretório não coincida com um padrão a ser ignorado, mas todo o conteúdo for ignorado, o diretório não será exibido, mas todo o resto do conteúdo será.

-z

Termine as entradas com NUL, em vez de LF. Isso implica no uso da opção --porcelain=v1 para o formato de saída caso nenhum outro formato tenha sido fornecido.

--column[=<opções>]
--no-column

Exiba os arquivos que não foram rastreados em colunas. Veja a variável de configuração column.status para conhecer a sintaxe desta opção.--column e --no-column sem estas opções, é o mesmo que always e never respectivamente.

--ahead-behind
--no-ahead-behind

Exibir ou não exibir contagens detalhadas de avanço/retrocesso para o ramo em relação ao ramo no topo. A predefinição é true.

--renames
--no-renames

Ativar/desativar a detecção de renomeação independentemente da configuração do usuário. Consulte também git-diff[1] --no-renames.

--find-renames[=<n>]

Ative a detecção de renomeação, definindo opcionalmente o limite de similaridade. Consulte também git-diff[1] --find-renames.

<pathspec>…​

Consulte a entrada pathspec em gitglossary[7].

SAÍDA

A saída desse comando foi projetada para ser usada como um comentário de modelo de commit. O formato padrão, longo, foi projetado para ser legível, detalhado e descritivo. Seu conteúdo e formato estão sujeitos a alterações a qualquer momento.

Os caminhos mencionados na saída, diferentemente de muitos outros comandos Git, são feitos em relação ao diretório atual. Caso esteja trabalhando em um subdiretório (isso é proposital, para ajudar a cortar e colar). Consulte a opção da configuração status.relativePaths abaixo.

Formato Curto

No formato curto, a condição de cada caminho é exibido como uma das seguintes formas

XY PATH
XY ORIG_PATH -> PATH

onde ORIG_PATH é de onde veio o conteúdo renomeado/copiado. O ORIG_PATH só é exibido quando a entrada é renomeada ou copiada. O XY é um código de condição com duas letras.

Os campos (incluindo o ->) estão separados um do outro por um único espaço. Caso um nome do arquivo contenha um espaço ou outros caracteres não imprimíveis, este campo será citado na forma de uma string C literal: cercado por caracteres ASCII com aspas duplas (34) e com os caracteres especiais internos escapados por barra invertida.

Existem três tipos de estados diferentes que são mostrados utilizando este formato e cada um utiliza a sintaxe XY de forma diferente:

  • Quando uma mesclagem está ocorrendo e a mesclagem foi bem sucedida ou esteja fora de uma mesclagem situação, X mostra o status do índice e o Y mostra o status da árvore de trabalho.

  • Quando o corre um conflito na mesclagem e ainda não foi resolvido, X e Y mostram o estado introduzido por cada cabeçalho da mesclagem com relação ao ancestral comum. Dizem que estes caminhos são unmerged ou não mesclados.

  • Quando um caminho é desmarcado, o X e o Y sempre são o mesmo, pois são desconhecidos ao índice. O ?? é usado para caminhos não rastreados. Os arquivos ignorados não são listados a menos que a opção --ignored seja usado; caso seja, os arquivos ignorados são indicados através do símbolo !!.

Observe que o termo merge aqui também inclui rebases usando a estratégia padrão --merge, cherry-picks e qualquer outra coisa que use o mecanismo da mesclagem.

Na tabela a seguir, estas três classes são mostradas em seções separadas e estes caracteres são usados nos campos X e`Y` para as primeiras duas seções que mostram o rastreamento dos caminhos:

  • ' ' = não modificado

  • M = modificado

  • T = tipo do arquivo que foi alterado (arquivo regular, link simbólico ou submódulo)

  • A = adicionado

  • D = excluído

  • R = renomeado

  • C = copiado (caso a condição da opção status.renames esteja definido como "copies" (cópias))

  • U = atualizado, mas não mesclado

X          Y     Significado
-------------------------------------------------
	 [AMD]   não atualizado
M        [MTD]  atualizado no índice
T        [MTD]  tipo alterado no índice
A        [MTD]  adicionado ao índice
D               excluído do índice
R        [MTD]  renomeado no índice
C        [MTD]  copiado no índice
[MTARC]         o índice e a árvore de trabalho coincidem
[MTARC]     M   a árvore de trabalho foi alterada desde o índice
[MTARC]     T   tipo alterado na árvore de trabalho desde o índice
[MTARC]     D   excluído na árvore de trabalho
	    R    renomeado na árvore de trabalho
	    C    copiado na árvore de trabalho
-------------------------------------------------
D           D    não mesclado, ambos excluídos
A           U    não mesclado, adicionado por nós
U           D    não mesclado, excluídos por eles
U           A    não mesclado, adicionados por eles
D           U    não mesclado, excluídos por nós
A           A    não mesclado, ambos foram adicionados
U           U    não mesclado, ambos foram alterados
-------------------------------------------------
?           ?    não rastreado
!           !    ignorado
-------------------------------------------------

Os submódulos têm mais estado e, em vez disso, relatam

  • M = o submódulo tem um HEAD diferente do registrado no índice

  • m = o submódulo tem o conteúdo modificado

  • ? = o submódulo tem arquivos não rastreados

Isso ocorre porque o conteúdo modificado ou os arquivos não rastreados num submódulo não podem ser adicionados através do comando git add no superprojeto para preparar um commit.

m e ? são aplicados recursivamente. Por exemplo, se um submódulo aninhado em um submódulo contiver um arquivo não rastreado, isso será relatado como ? também.

Caso -b seja utilizado, a condição de formato curto será precedido por uma linhas

## info de  rastreio do nome do ramo

Formato de Porcelana Versão 1

O formato porcelana da versão 1 é semelhante ao formato curto, mas é garantido que não será alterado de forma incompatível com as versões anteriores entre as versões do Git ou com base na configuração do usuário. Isso o torna ideal para ser analisado por scripts. A descrição do formato curto acima também descreve o formato de porcelana, com algumas exceções:

  1. Caso a configuração da variável color.status do usuário não seja respeitada; a cor estará sempre desligada.

  2. Caso a configuração da variável status.relativePaths do usuário não seja respeitada; os caminhos exibidos sempre serão relativos à raiz do repositório.

Há também um formato alternativo -z recomendado para análise de máquina. Neste formato, o campo de status é o mesmo, mas algumas outras coisas mudam. Primeiro, o -> é omitido das entradas de renomeação e a ordem dos campos é invertida (from -> to se torna to from por exemplo). Em segundo lugar, um NUL (ASCII 0) segue cada nome de arquivo, substituindo o espaço como separador de campo e a nova linha de encerramento (mas um espaço ainda separa o campo de status do primeiro nome de arquivo). Terceiro, os nomes de arquivos que contêm caracteres especiais não são formatados de maneira especial; não são feitas aspas ou recapitulação de barra invertida.

Quaisquer alterações no submódulo são relatadas como M modificado em vez de m ou um único ?.

Formato de Porcelana Versão 2

O formato da versão 2 adiciona informações mais detalhadas sobre o estado da árvore de trabalho e os itens alterados. A versão 2 também define um conjunto extensível de cabeçalhos opcionais fáceis de analisar.

As linhas de cabeçalho começam com # e são adicionadas em resposta a argumentos específicos da linha de comando. Os analisadores devem ignorar os cabeçalhos que não reconhecem.

Cabeçalho dos Ramos

Caso --branch seja utilizado, uma série de linhas de cabeçalho será impressa com as informações sobre a ramificação atual.

Linha                                     Notas
------------------------------------------------------------
# branch.oid <commit> | (initial)        Commit atual.
# branch.head <branch> | (detached)      Ramo atual.
# branch.upstream <ramo-do-topo>      se o topo for definido.
# branch.ab +<ahead> -<behind>           se o topo for definido e
					 o commit estiver presente.
------------------------------------------------------------

Informação do empilhamento

Caso a opção --show-stash seja usada, uma linha será impressa mostrando a quantidade das entradas que estão empilhadas caso não seja zero:

# stash <N>

Entradas Rastreadas que Foram Alteradas

Após os cabeçalhos, uma série de linhas é impressa para as entradas rastreadas. Um dos três formatos diferentes de linha pode ser usado para descrever uma entrada, dependendo do tipo de alteração. As entradas rastreadas são impressas numa ordem indefinida; os analisadores devem permitir uma mistura dos três tipos de linha em qualquer ordem.

Os itens comuns que foram alterados têm o seguinte formato:

1 <XY> <sub> <mH> <mI> <mW> <hH> <hI> <caminho>

As entradas que foram renomeadas ou copiadas têm o seguinte formato:

2 <XY> <sub> <mH> <mI> <mW> <hH> <hI> <X><score> <caminho><sep><caminho original>
Campo       Significado
--------------------------------------------------------
<XY>        Um campo com 2 characteres contendo valores XY
	    montados e não montados descrito em um formato curto,
	    sem modificações indicadas por um "." em vez de
	    um espaço.
<sub>       Um campo com 4 caracteres descrevendo a condição do submódulo.
	    "N..." quando a entrada não for um submódulo.
	    "S<c><m><u>" quando a entrada for um submódulo.
	    <c> is "C" caso o commit seja modificado; senão ".".
	    <m> is "M" caso haja mudanças rastreadas; senão ".".
	    <u> is "U" caso não haja mudanças rastreadas; senão ".".
<mH>        O modo de um arquivo octal no HEAD.
<mI>        O modo de um arquivo octal no índice.
<mW>        O modo de um arquivo octal na árvore de trabalho.
<hH>        O nome do objeto no HEAD.
<hI>        O nome do objeto no índice.
<X><score>  O renomeamento ou a cópia do score "placar"(denota a porcentagem
	    ou a similaridade entre a fonte e o destino da ação de
	    mover ou copiar. Por exemplo, "R100" ou "C75".
<caminho>      O `pathname` "nome do caminho".  Em um lançamento de renomeação/cópia,
	    este é o caminho de destino.
<sep>       Quando a opção `-z` for utilizada, os 2 `pathnames` são separados
	    com um byte `NUL` (ASCII 0x00); senão um byte tab (ASCII 0x09)
	    que os separam.
<origPath>  O `pathname` dentro do commit localizado no HEAD ou no índice.
	    Só está presente no caso de um lançamento de renomeação ou cópia
	    assim como informa de onde a renomeação ou cópia vieram.
--------------------------------------------------------

As entradas que não forem mescladas têm o seguinte formato; o primeiro caractere é um "u" para se distinguir das entradas comum que foram alteradas.

u <XY> <sub> <m1> <m2> <m3> <mW> <h1> <h2> <h3> <caminho>
Campo       Significado
--------------------------------------------------------
<XY>        Um campo com 2 caracteres descrevendo o tipo de conflito
	    como descrito em um formato curto.
<sub>       Um campo com 4 caracteres descrevendo a condição do submódulo
	    como descrito abaixo.
<m1>        O modo de um arquivo octal no estágio 1.
<m2>        O modo de um arquivo octal no estágio 2.
<m3>        O modo de um arquivo octal no estágio 3.
<mW>        O modo de um arquivo octal na árvore de trabalho.
<h1>        O nome do objeto no estágio 1.
<h1>        O nome do objeto no estágio 2.
<h1>        O nome do objeto no estágio 3.
<caminho>      O `pathname` "nome do caminho".
--------------------------------------------------------

Outros itens

Após as entradas rastreadas (se for solicitado), uma série de linhas será impressa para os itens não rastreados e depois ignorados para os itens encontrados na árvore de trabalho.

Itens não rastreados têm o seguinte formato:

? <caminho>

Os itens ignorados tem o seguinte formato:

! <caminho>

Notas sobre o formato do pathname e -z

Quando a opção -z é fornecida, os nomes de caminho são impressos como estão, sem aspas, e as linhas são encerradas com um byte NUL (ASCII 0x00).

Sem a opção -z, os pathnames com os caracteres "incomuns" são citados conforme explicado na variável de configuração core.quotePath (consulte git-config[1]).

CONFIGURAÇÃO

O comando segue a variável color.status (ou status.color, ambos têm o mesmo significado, o último é mantido para compatibilidade com versões anteriores). As variáveis de configuração color.status. serve para para colorir a saída.

Se a variável de configuração status.relativePaths estiver configurada como false, todos os caminhos exibidos serão relativos à raiz do repositório e não ao diretório atual.

Se a variável status.submoduleSummary for definida como um número diferente de zero ou true (idêntico a -1 ou um número ilimitado), o resumo do submódulo será ativado para o formato longo e um resumo dos commits para os submódulos modificados serão exibidos (consulte a opção --summary-limit de git-submodule[1]). Por favor note que a saída resumida do comando status será suprimida para todos os submódulos quando a variável diff.ignoreSubmodules estiver definida como all ou apenas para aqueles submódulos em onde seja o mesmo que submodule.<nome>.ignore=all. Para visualizar também o resumo dos submódulos ignorados, você pode usar a opção de clinha de comando --ignore-submodules=dirty ` ou o comando `git submodule summary, que exibe uma saída semelhante porém não respeita estas configurações.

RENOVAÇÃO DO PLANO DE FUNDO

É predefinido que o comando git status renove automaticamente o índice, as estatísticas das informações armazenadas no cache da árvore de trabalho e gravando o seu resultado. Escrever o índice atualizado é uma otimização que não é estritamente necessária (o status calcula os valores por si só, mas escrevê-los é apenas para evitar que os programas subsequentes repitam o nosso processamento). Quando o status é executado em segundo plano, o bloqueio retido durante a gravação pode entrar em conflito com os outros processos simultâneos, causando falhas. Os scripts que executam status em segundo plano devem considerar a utilização do comando git --no-optional-locks status (para mais detalhes consulte git[1]).

ARQUIVOS NÃO RASTREADOS E DESEMPENHO

O comando git status pode ser muito lento em grandes árvores de trabalho se/quando precisar procurar arquivos e diretórios não rastreados. Existem muitas opções de configuração disponíveis para acelerar isso, evitando o trabalho ou fazendo o uso dos resultados já em cache dos comandos anteriores do Git. Não existe um único conjunto ideal de configurações que sejam corretas para todos. Para ajudá-lo, vamos listar um resumo das opções relevantes, porém, antes de entrar na lista, talvez você queira executar o comando git status novamente, pois a sua configuração já pode estar armazenada em cache com os resultados do git status, assim pode ficar mais rápido nas execuções posteriores.

  • A opção --untracked-files=no ou o status.showUntrackedFiles=no config (see above for both): indicate that git status should not report untracked files. This is the fastest option. git status will not list the untracked files, so you need to be careful to remember if you create any new files and manually git add them.

  • advice.statusUoption=false (consulte git-config[1]): A definição dessa variável como false desativa a mensagem de aviso fornecida quando a enumeração dos arquivos não rastreados leva mais de 2 segundos. Num grande projeto, isso pode levar mais tempo e o usuário pode já ter aceitado a troca (usar -uno pode não ser uma opção aceitável para o usuário por exemplo), onde não faz sentido emitir a mensagem de aviso e, nesse caso, desativar o aviso pode ser o melhor.

  • core.untrackedCache=true (consulte git-update-index[1]): Ative o recurso de cache não rastreado e pesquise apenas os diretórios que foram alterados desde o comando git status anterior. O Git lembra o conjunto de arquivos não rastreados dentro de cada diretório e presume que, se um diretório não tiver sido modificado, o conjunto de arquivos não rastreados dentro dele não foi alterado. Isso é muito mais rápido do que enumerar o conteúdo de cada diretório, mas ainda assim não é isento de custos, porque o Git ainda precisa procurar o conjunto de diretórios alterados. O cache não rastreado é armazenado no arquivo .git/index. O custo reduzido da pesquisa de arquivos não rastreados é ligeiramente compensado pelo aumento do tamanho do índice e pelo custo de mantê-lo atualizado. A redução do tempo de pesquisa geralmente compensa o tamanho adicional.

  • core.untrackedCache=true e core.fsmonitor=true ou O core.fsmonitor=<hook-command-pathname> (consulte git-update-index[1]): ative os recursos de cache não rastreado e FSMonitor e pesquise apenas os diretórios que foram alterados desde o comando git status anterior. Isso é mais rápido do que usar apenas o cache não rastreado, porque o Git também pode evitar a busca por diretórios alterados. O Git só precisa enumerar o conjunto exato de diretórios que foram alterados recentemente. Embora o recurso FSMonitor possa ser ativado sem o cache não rastreado, os benefícios são muito reduzidos nesse caso.

Observe que, após ativar o cache não rastreado e/ou os recursos do FSMonitor, podem ser necessários alguns comandos git status para que os vários caches se aqueçam antes que você veja melhores tempos de comando. Isso é normal.

VEJA TAMBÉM

GIT

Parte do conjunto git[1]

scroll-to-top