Setup and Config
Getting and Creating Projects
Basic Snapshotting
Branching and Merging
Sharing and Updating Projects
Inspection and Comparison
Patching
Debugging
External Systems
Server Admin
Guides
- gitattributes
- Command-line interface conventions
- Everyday Git
- Frequently Asked Questions (FAQ)
- Glossary
- Hooks
- gitignore
- gitmodules
- Revisions
- Submodules
- Tutorial
- Workflows
- All guides...
Administration
Plumbing Commands
- 2.45.1 → 2.47.1 no changes
- 2.45.0 04/29/24
- 2.44.1 → 2.44.2 no changes
- 2.44.0 02/23/24
- 2.43.1 → 2.43.5 no changes
- 2.43.0 11/20/23
- 2.40.1 → 2.42.3 no changes
- 2.40.0 03/12/23
- 2.39.1 → 2.39.5 no changes
- 2.39.0 12/12/22
- 2.35.1 → 2.38.5 no changes
- 2.35.0 01/24/22
- 2.34.1 → 2.34.8 no changes
- 2.34.0 11/15/21
- 2.31.1 → 2.33.8 no changes
- 2.31.0 03/15/21
- 2.30.2 → 2.30.9 no changes
- 2.30.1 02/08/21
- 2.24.1 → 2.30.0 no changes
- 2.24.0 11/04/19
- 2.22.1 → 2.23.4 no changes
- 2.22.0 06/07/19
- 2.21.1 → 2.21.4 no changes
- 2.21.0 02/24/19
- 2.19.1 → 2.20.5 no changes
- 2.19.0 09/10/18
- 2.18.1 → 2.18.5 no changes
- 2.18.0 06/21/18
- 2.17.1 → 2.17.6 no changes
- 2.17.0 04/02/18
- 2.16.6 12/06/19
- 2.15.4 no changes
- 2.14.6 12/06/19
- 2.13.7 05/22/18
- 2.12.5 no changes
- 2.11.4 09/22/17
- 2.7.6 → 2.10.5 no changes
- 2.6.7 05/05/17
- 2.5.6 05/05/17
- 2.4.12 05/05/17
- 2.3.10 no changes
- 2.2.3 09/04/15
- 2.1.4 no changes
- 2.0.5 12/17/14
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 comandogit 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 specifyingnormal
), 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 (seegit update-index --untracked-cache
andgit update-index --split-index
), Otherwise you can useno
to havegit status
return more quickly without showing untracked files. All usual spellings for Boolean valuetrue
are taken asnormal
andfalse
asno
.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çãostatus.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 oY
mostra o status da árvore de trabalho. -
Quando o corre um conflito na mesclagem e ainda não foi resolvido,
X
eY
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 oY
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:
-
Caso a configuração da variável
color.status
do usuário não seja respeitada; a cor estará sempre desligada. -
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 ostatus.showUntrackedFiles=no
config (see above for both): indicate thatgit 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 manuallygit add
them. -
advice.statusUoption=false
(consulte git-config[1]): A definição dessa variável comofalse
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 comandogit 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
ecore.fsmonitor=true
ou Ocore.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 comandogit 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.
GIT
Parte do conjunto git[1]