Git

git-show last updated in 2.34.1

NOME

git-show - Exibe vários tipos de objetos

RESUMO

git show [<opções>] [<objeto>…]

DESCRIÇÃO

Exibe um ou mais objetos (bolhas, árvores, tags e commits).

Para commits, exibe a mensagem do registro log e a diferença textual. Ele também apresenta o commit de mesclagem em um formato especial, produzido por git diff-tree --cc.

Para tags, ele exibe a mensagem da tag e os objetos referenciados.

Para árvores, ele exibe os nomes (equivalente a git ls-tree com --name-only).

Para gotas simples, exibe o conteúdo simples.

O comando aceita as opções aplicáveis ao comando git diff-tree para controlar como as modificações feitas pelo commit são exibidas.

Esta página do manual descreve apenas as opções utilizadas com mais frequência.

OPÇÕES

<objeto>…: Os nomes dos objetos a serem exibidos (a predefinição retorna para HEAD). Para obter uma lista mais completa de maneiras de soletrar os nomes dos objetos, consulte a seção "DEFININDO AS REVISÕES" em gitrevisions[7].
--pretty[=<formato>]
--format=<formato>: Faça uma impressão bonita do conteúdo do registro log do commit em determinado formato, onde <formato> pode ser oneline, short, medium, full, fuller, reference, email, raw, format:<texto> e tformat:<texto>. Quando <formato> não for nenhum dos itens acima e possua um %placeholder, ele age como se a opção ‘--pretty=tformat:<formato>’ tenha sido utilizado.

Consulte a seção "FORMATOS BONITOS" para obter detalhes adicionais para cada formato. Quando a parte do =<formato> é omitido a predefinição retorna para medium.

Nota: você pode especificar o formato "pretty" padrão na configuração do repositório (consulte git-config[1]).
--abbrev-commit: Em vez de exibir todos os 40 bytes hexadecimais do nome do objeto commit, exiba apenas um prefixo parcial. A quantidade dos dígitos não predefinidos podem ser definidos com a opção "--abbrev=<n>" (que também altera o diff gerado, caso seja exibido).

Isso deve tornar --pretty=oneline muito mais legível para pessoas que usam terminais com 80 colunas.
--no-abbrev-commit: Exibe o nome do objeto commit completo com 40 bytes hexadecimais. Isso nega o a opção --abbrev-commit e as opções que o implicam, como --oneline. Ele também substitui a variável log.abbrevCommit.
--oneline: Este é um atalho para "--pretty=oneline --abbrev-commit" ser utilizado junto.
--encoding=<codificação>: Os objetos commit registram a codificação utilizada para a mensagem do registro log em seu cabeçalho de codificação; esta opção pode ser usada para informar ao comando para novamente codificar a mensagem do registro log do commit na codificação preferida pelo usuário. Para os comandos não redirecionáveis, a predefinição retorna para UTF-8. Observe que caso um objeto afirma ser codificado com X e estamos gerando em` X`, o objeto será gerado de forma literal; isso significa que as sequências inválidas no commit original podem ser copiadas para a saída.
--expand-tabs=<n>
--expand-tabs
--no-expand-tabs: Execute uma expansão de guia (substitua cada guia por espaços suficientes para preencher a próxima coluna da exibição que é o múltiplo de <n>) na mensagem do registro log antes de exibi-la na saída. A opção --expand-tabs é uma abreviação da opção --expand-tabs=8, a opção --no-expand-tabs é uma abreviação da opção --expand-tabs=0, que desativa a expansão da guia.

A predefinição é que as guias sejam expandidas em belos formatos que recuam a mensagem do registro log em 4 espaços (ou seja, medium, a predefinição, full e fuller).
--notes[=<ref>]: Exiba as anotações (consulte git-notes[1]) que acompanham o commit durante a exibição da mensagem do registro log do commit. Este é a predefinição para os comandos git log, git show e git whatchanged quando não haja nenhuma opção --pretty, --format ou --oneline utilizada na linha de comando.

É predefinido que as anotações exibidas são das anotações refs listadas nas variáveis core.notesRef e notes.displayRef (ou substituições correspondentes do ambiente). Para mais detalhes consulte git-config[1].

Com um argumento opcional <ref>, usa a "ref" para encontrar as notas que serão exibidas. A "ref" pode definir o nome completo da "ref" quando começar com refs/notes/; quando começa com notes/, refs/ e caso contrário refs/notes/ é prefixado para formar um nome completo da "ref".

Várias opções --notes podem ser combinadas para controlar quais as notas estão sendo exibidas. Exemplos: --notes=foo mostrará apenas as notas vindas de "refs/notes/foo"; --notes=foo --notes mostrará as notas vindas de "refs/notes/foo" e das notas ref(s) predefinidas.
--no-notes: Não exiba as anotações. Isso nega a opção --notes acima, redefinindo a lista das anotações das refs a partir de onde as notas são exibidas. As opções são analisadas na ordem informada na linha de comando, portanto, "--notes --notes=foo --no-notes --notes=bar" exibirá apenas as anotações das "refs/notes/bar" por exemplo.
--show-notes[=<ref>]
--[no-]standard-notes: Essas opções estão obsoletas. Em vez disso, utilize as opções --notes/--no-notes acima.
--show-signature: Verifique a validade de um objeto commit assinado, passando a assinatura para gpg --verify e exibe a sua saída.

FORMATOS BONITOS

Se o commit for uma mesclagem e se o formato bonito não for oneline, email ou raw, uma linha adicional será inserida antes da linha Author:. Esta linha começa com "Mesclar:" e os hashes dos commits anteriores são exibidos, separados por espaços. Observe que os commits listados podem não ser necessariamente a lista direta dos commits relacionados se você limitou sua visão do histórico: por exemplo, se você estiver interessado apenas em alterações relacionadas a um determinado diretório ou arquivo.

Existem vários formatos incorporados e você pode definir formatos adicionais ao definir uma opção da configuração pretty.<nome> para um outro nome de formato ou uma string format:, conforme descrito abaixo (consulte git-config[1]). Aqui estão os detalhes dos formatos incorporados: Aqui estão os detalhes dos formatos incorporados:

oneline
```
<hash> <linha do título>
```
Isso foi desenvolvido para ser o mais compacto possível.

short

commit <hash>
Author: <autor>

<linha do título>

medium

commit <hash>
Author: <autor>
Date:   <data do autor>

<linha do título>

<mensagem completa do commit>

full

commit <hash>
Author: <autor>
Commit: <quem fez o commit>

<linha do título>

<mensagem completa do commit>

fuller

commit <hash>
Author:     <autor>
AuthorDate: <data do autor>
Commit:     <quem fez o commit>
CommitDate: <a data de quem fez o commit>

<linha do título>

<mensagem completa do commit>

reference
```
<abbrev hash> (<linha do título>, <data do autor abreviada>)
```
Este formato é utilizado para se referir a outro commit em uma mensagem de commit e é o mesmo que o formato --pretty='format:%C(auto)%h (%s, %ad)'. Por predefinição a data é formatada com --date=short, a menos que outra opção --date seja utilizada de forma explicita. Como em qualquer formato format: com marcadores de formato, a sua saída não é afetada por outras opções como --decorate e --walk-reflogs.

email

From <hash> <data>
From: <autor>
Date: <data do autor>
Subject: [PATCH] <linha do título>

<mensagem completa do commit>

mboxrd

Como e-mail, porém as linhas no commit da mensagem iniciando com "From" (precedidas por zero ou mais ">") são citadas com ">" para que não sejam confundidas ao iniciar um novo commit.
raw

O formato bruto exibe todo o commit exatamente como foi armazenado no objeto commit. Notavelmente, os hashes são exibidos na íntegra independentemente se a opção --abbrev ou --no-abbrev foram utilizadas, as informações relacionadas as origens parents demonstram quais os verdadeiros commits da origem sem levar em consideração os enxertos ou a simplificação do histórico. Observe que este formato afeta a maneira como os commits são exibidos mas não a maneira como o "diff" é exibido com git log --raw por exemplo. Para obter os nomes completos e sem abreviações dos objetos em formato diff bruto, utilize --no-abbrev.
format:<texto>

O formato format:<texto> permite especificar quais as informações que você deseja exibir. Funciona um pouco como o formato "printf" com a exceção notável de que você obtém uma nova linha com %n em vez de \n.

Por exemplo,format:"O autor do %h foi %an, %ar%nO título era >>%s<<%n" exibirá algo como isso:
```
O autor do fe6e0ee foi Junio C Hamano, 23 houras atrás
O título era >>t4119: test autocomputing -p<n> for traditional diff input.<<
```
Os espaços reservados são:
- O Espaços reservados que se expandem para um único caractere literal:
  
  %n
  
  newline
  
  %%
  
  a raw %
  
  %x00
  
  imprime um byte de um código hexadecimal
- Espaços reservados que afetam a formatação de espaços reservados posteriores:
  
  %Cred
  
  mudar de cor para o vermelho
  
  %Cgreen
  
  mudar de cor para o verde
  
  %Cblue
  
  mudar de cor para o azul
  
  %Creset
  
  redefine a cor
  
  %C(…)
  
  definições das cores, conforme descrito em Valores no "ARQUIVO DE CONFIGURAÇÃO" seção do git-config[1]. É predefinido que as cores sejam exibidas apenas quando ativadas para na saída do registro log (em color.diff,` color.ui` ou color, e respeitando as configurações auto da primeira se estivermos indo para um terminal). %C(auto,...) é aceito como um sinônimo histórico do padrão (exemplo., %C(auto,red)). Especificar %C(always,...) exibirá as cores mesmo quando a cor não estiver ativada (embora considere apenas usar --color=always para sempre ativar a cor na saída incluindo este formato e qualquer outro que o git possa colorir). auto sozinho (ou seja,%C(auto)) ativará a coloração automática nos próximos espaços reservados até que a cor seja trocada novamente.
  
  %m
  
  marca esquerda (<), direita (>) ou limite (-)
  
  %w([<w>[,<i1>[,<i2>]]])
  
  alterna a quebra de linha, como a opção -w de git-shortlog[1].
  
  %<(<N>[,trunc|ltrunc|mtrunc])
  
  faça com que o próximo espaço reservado leve em menos N colunas, preenchendo espaços à direita, se necessário. Opcionalmente, truncar no início (ltrunc), no meio (mtrunc) ou no final (trunc) caso a saída seja maior que N colunas. Observe que o truncamento funciona corretamente com N >= 2.
  
  %<|(<N>)
  
  faça com que o próximo espaço reservado leve pelo menos até a enésima colunas, preenchimento de espaços à direita se necessário
  
  %>(<N>), %>|(<N>)
  
  semelhante a %<(<N>), %<|(<N>) respectivamente, mas com espaços de preenchimento à esquerda
  
  %>>(<N>), %>>|(<N>)
  
  semelhante a %>(<N>), %>|(<N>) respectivamente, exceto caso o próximo espaço reservado ocupe mais espaços do que o informado e haja espaços à esquerda, utilize estes espaços
  
  %><(<N>), %><|(<N>)
  
  semelhante a %<(<N>), %<|(<N>) respectivamente, mas preenchendo os dois lados (ou seja, o texto é centralizado)
- Espaços reservados que se expandem para as informações extraídas do commit:
  %H
  
  hash do commit
  
  %h
  
  abreviação do hash do commit
  
  %T
  
  hash da árvore
  
  %t
  
  hash abreviado da árvore
  
  %P
  
  hash das origens
  
  %p
  
  hash abreviado das origens
  
  %an
  
  nome do autor
  
  %aN
  
  nome do autor (respeitando .mailmap, consulte git-shortlog[1] ou git-blame[1])
  
  %ae
  
  e-mail do autor
  
  %aE
  
  e-mail do autor (respeitando .mailmap, consulte git-shortlog[1] ou git-blame[1])
  
  %al
  
  parte local do e-mail do autor (a parte antes do sinal @)
  
  %aL
  
  parte local do autor (consulte %al) respeitando .mailmap, consulte git-shortlog[1] ou git-blame[1])
  
  %ad
  
  data do autor (o formato respeita a opção --date=)
  
  %aD
  
  data do autor, no padrão RFC2822
  
  %ar
  
  data do autor, relativa
  
  %at
  
  data do autor, com registro de data e hora em formato UNIX
  
  %ai
  
  data do autor, formato parecido com ISO 8601
  
  %aI
  
  data do autor, formato rigoroso ao padrão ISO 8601
  
  %as
  
  data do autor, formato curto (AAAA-MM-DD)
  
  %cn
  
  nome de quem fez o commit
  
  %cN
  
  nome de quem fez o commit (respeitando .mailmap, consulte git-shortlog[1] ou git-blame[1])
  
  %ce
  
  endereço do e-mail de quem fez o commit
  
  %cE
  
  e-mail de quem fez o commit (respeitando .mailmap, consulte git-shortlog[1] ou git-blame[1])
  
  %cl
  
  parte local do e-mail de quem fez o commit (a parte antes do sinal @)
  
  %cL
  
  parte local de quem fez o commit (consulte %cl) respeitando o .mailmap, consulte git-shortlog[1] ou git-blame[1])
  
  %cd
  
  data do commit (o formato respeita a opção --date=)
  
  %cD
  
  data do commit, no padrão RFC2822
  
  %cr
  
  data do commit, relativa
  
  %ct
  
  data do commit, com registro de data e hora em formato UNIX
  
  %ci
  
  data do commit, formato parecido com ISO 8601
  
  %cI
  
  data do commit, formato rigoroso ao padrão ISO 8601
  
  %cs
  
  data do commit, formato curto (AAAA-MM-DD)
  
  %d
  
  nomes de referência "ref", como a opção --decorate do git-log[1]
  
  %D
  
  nomes de referência "ref" sem quebra automática " (", ")".
  
  %S
  
  nomes "ref" dado na linha de comando pela qual o commit foi alcançado (como git log --source), só funciona com git log
  
  %e
  
  codificação
  
  %s
  
  assunto
  
  %f
  
  linha do assunto higienizado, adequado para um nome de arquivo
  
  %b
  
  corpo
  
  %B
  
  corpo bruto (assunto e corpo da mensagem desembrulhados)
  
  %N
  
  anotações de quem fez o commit
  
  %GG
  
  verificação bruta da mensagem vinda do GPG para um commit assinado
  
  %G?
  
  exibe "G" para obter uma boa assinatura (válida), "B" para uma assinatura ruim, "U" para uma boa assinatura com validade desconhecida, "X" para uma boa assinatura que expirou, "Y" para uma boa assinatura feita por uma chave expirada, "R" para uma boa assinatura feita por uma chave revogada, "E" caso a assinatura não possa ser verificada (por exemplo, uma chave ausente) e "N" sem assinatura
  
  %GS
  
  exibe o nome do assinante de um commit assinado
  
  %GK
  
  exibe a chave utilizada para assinar um commit assinado
  
  %GF
  
  exiba a impressão digital da chave utilizada para assinar um commit já assinado
  
  %GP
  
  exiba a impressão digital da chave primária cuja subchave foi utilizada para assinar um commit assinado
  
  %GT
  
  exiba o nível de confiança da chave utilizada para assinar um commit assinado
  
  %gD
  
  seletor do "reflog", por exemplo, refs/stash@{1} ou refs/stash@{2 minutos atrás} `; o formato segue as regras descritas para a opção `-g. A parte antes ao @ é o "refname", conforme indicado na linha de comando (portanto, git log -g refs/heads/master produziria refs/heads/master@{0}).
  
  %gd
  
  seletor do reflog encurtado; o mesmo que %gD, menos o "refname" a parte é reduzida visando a legibilidade humana (assim, refs/heads/master se torna apenas master).
  
  %gn
  
  nome da identidade "reflog"
  
  %gN
  
  nome da identidade reflog (respeitando .mailmap, consulte git-shortlog[1] ou git-blame[1])
  
  %ge
  
  e-mail da identidade reflog
  
  %gE
  
  e-mail da identidade reflog (respeitando .mailmap, consulte git-shortlog[1] ou git-blame[1])
  
  %gs
  
  assunto reflog
  
  %(trailers[:options])
  
  exiba os sinais de resposta no corpo da mensagem como interpretado por git-interpret-trailers[1]. A carreira de caracteres de resposta pode ser seguida por dois pontos e zero ou mais opções separadas por vírgula:
  
  key=<K>: exibe apenas os caracteres de resposta com as chaves que forem definidas. A combinação é feita sem distinção entre maiúsculas e minúsculas, os dois pontos à direita são opcionais. Caso a opção seja utilizada várias vezes, os atributos das linhas coincidentes a qualquer uma das teclas serão exibidas. Esta opção ativa automaticamente a opção only, para que as linhas de bloqueio não sejam ocultadas. Caso não seja o efeito desejado, pode ser desativado com a opção only=false. Por exemplo, %(trailers:key=Revisado-por) exibe as linhas com caracteres de resposta com a chave Revisado-por.
  
  only[=val]: seleciona se o atributo das linhas dos caracteres de resposta devem ser incluídos. A palavra-chave only pode opcionalmente ser seguido por um sinal de igual e uma das opções true, on, yes para omitir ou false, off, no para exibir as linhas que não sejam caracteres de resposta. Caso a opção seja usada sem qualquer valor, ela será ativada. Caso seja usado várias vezes, apenas o último valor será considerado.
  
  separator=<SEP>: defina um separador inserido entre as linhas dos caracteres de resposta. Quando esta opção não é utilizada, cada linha do caractere de resposta é finalizada com um caractere de avanço da linha. A sequência SEP poderá conter os códigos de formatação literal descritos acima. Para usar uma vírgula como separador, é necessário utilizar %x2C, pois caso contrário, seria analisado como fosse uma próxima opção. Caso a opção separadora seja utilizada várias vezes, apenas a última será levada em consideração. Como por exemplo, %(trailers:key=Ticket,separator=%x2C ) mostra todas as linhas do caractere de resposta cuja chave é "Ticket" separada por vírgula e espaço.
  
  unfold[=val]: faça com que se comporte como se a opção do interpretador do caractere de resposta da opção --unfold tenha sido utilizada. Da mesma maneira que only, .que pode ser seguido através de um sinal de igual ou valores explícitos. Como por exemplo, %(trailers:only,unfold=true) revela e exibe todas as linhas dos caracteres de resposta.
  
  valueonly[=val]: ignore a parte principal da linha caractere de resposta e exiba apenas a parte do valor. Além disso, isto também permite que o valor seja explícito de maneira opcional.

Note

Alguns espaços reservados podem depender das outras opções passadas para o motor percorrer a revisão. Por exemplo o opção %g* do reflog insere um espaço vazio a menos que estejamos percorrendo as entradas do reflog (exemplo, através do comando git log -g). Os espaços reservados %d e %D usarão o formato de decoração "curta" caso a opção --decorate já não esteja sendo utilizada na linha de comando.

Caso adicionemos um + (sinal de adição) após o % de um espaço reservado, um feed de linha será inserido imediatamente antes da expansão, se e somente se o espaço reservado se expandir para uma sequência de caracteres não vazio.

Caso adicione um - (sinal de menos) após o % de um espaço reservado, imediatamente todos os feeds consecutivos das linhas anteriores à expansão serão excluídos caso e somente caso o espaço reservado se expanda para um texto vazio.

Caso adicionemos um ` ` (espaço) após o % de um espaço reservado, um espaço será inserido imediatamente antes da expansão, se e somente se o espaço reservado se expandir para uma sequência de caracteres não vazios.

tformat:

O formato tformat: funciona exatamente como format:, exceto que ele provê a semântica "terminator" (terminador) em vez do "separator" (separador). Em outras palavras, cada commit tem o caractere terminador da mensagem (geralmente uma nova linha) adicionada em vez de um separador colocado entre as entradas. Significa que o final de cada entrada do formato de uma linha única será terminada corretamente com uma nova linha, assim como o formato com uma linha faz (oneline). Por exemplo:
```
$ git log -2 --pretty=format:%h 4da45bef \
  | perl -pe '$_ .= " -- NO NEWLINE\n" unless /\n/'
4da45be
7134973 -- NO NEWLINE

$ git log -2 --pretty=tformat:%h 4da45bef \
  | perl -pe '$_ .= " -- NO NEWLINE\n" unless /\n/'
4da45be
7134973
```
Além disso, qualquer string não reconhecida que tenha um % nela, é interpretada como se tivesse tformat: na frente. Como por exemplo, estes dois são equivalentes:
```
$ git log -2 --pretty=tformat:%h 4da45bef
$ git log -2 --pretty=%h 4da45bef
```

OPÇÕES DIFF QUE SÃO COMUNS

-p

-u

--patch

Gere um patch (consulte a seção sobre a geração de patches).

-s

--no-patch

Suprime a saída diff. Útil para comandos como git show que por predefinição exibem a correção ou para cancelar o efeito de --patch.

-U<n>

--unified=<n>

Gere diffs com uma quantidade de <n> linhas de contexto em vez das três usuais. Implica no uso da opção --patch. Implica no uso da opção -p.

--output=<arquivo>

Escreve o arquivo para um determinado arquivo em vez de stdout.

--output-indicator-new=<caractere>

--output-indicator-old=<caractere>

--output-indicator-context=<caractere>

Informe o caractere que será utilizado para indicar as linhas novas, antigas ou do contexto no patch que foi gerado. Normalmente eles são +, - e ' ' respectivamente.

--raw

Para cada commit, exiba um resumo das alterações utilizando o formato diff bruto. Consulte a seção "GERANDO O FORMATO BRUTO" git-diff[1]. É diferente de exibir o próprio registro log em formato bruto, que pode ser obtido com a opção --format=raw.

--patch-with-raw

É um sinônimo para -p --raw.

--indent-heuristic

Ativa a heurística que altera os limites dos pedaços diferentes para facilitar a leitura dos patches. Esta é a predefinição.

--no-indent-heuristic

Desative a heurística de recuo.

--minimal

Expenda um tempo extra para garantir que o menor diferencial possível seja produzido.

--patience

Gere um diff utilizando o algoritmo "patience diff" (ou diff de paciência).

--histogram

Gere um diff utilizando o algoritmo "histogram diff" (ou diff de histograma).

--anchored=<texto>

Gere um diff utilizando o algoritmo "anchored diff" (ou diff ancorado).

Esta opção pode ser especificada mais de uma vez.

Caso uma linha exista na origem e no destino, exista apenas uma vez e comece com este texto, este algoritmo tenta impedir que apareça como uma exclusão ou adição na saída. O algoritmo "patience diff" é utilizado internamente.

--diff-algorithm={patience|minimal|histogram|myers}

Escolha um algoritmo diff. As variantes são as seguintes:

default, myers: O algoritmo diff ganancioso básico. Atualmente, este é o valor predefinido.
minimal: Expenda um tempo extra para garantir que o menor diferencial possível seja produzido.
patience: Utilize o algoritmo "patience diff" (ou diff de paciência) ao gerar os patches.
histogram: Este algoritmo estende o algoritmo "patience" (paciência) para "se compatível com os elementos comuns com baixa ocorrência".

Caso tenha configurado uma variável diff.algorithm para um valor sem predefinição e quer utilizar a variável predefinida por exemplo, então utilize a opção --diff-algorithm=default.

--stat[=<largura>[,<largura-do-nome>[,<count>]]]

Gera um diffstat. É predefinido que o espaço necessário será utilizado para a parte do nome do arquivo e o restante para a parte do grafo. A largura máxima a predefinição retorna para a largura do terminal ou 80 colunas, caso não esteja conectada em um terminal e pode ser substituída por <largura>. A largura da parte do nome do arquivo pode ser limitada, fornecendo outra largura <largura-do-nome> após uma vírgula. A largura da parte do grafo pode ser limitada utilizando --stat-graph-width=<largura> (afeta todos os comandos que geram um grafo estatístico) ou definindo diff.statGraphWidth=<largura> (não afeta o git format-patch). Ao fornecer um terceiro parâmetro <count>, é possível limitar a saída às primeiras linhas <count>, seguidas por ... caso haja mais.

Estes parâmetros também podem ser ajustados individualmente com --stat-width=<largura>, --stat-name-width=<largura-do-nome> e --stat-count=<count>.

--compact-summary

A saída de um resumo condensado das informações do cabeçalho estendido como criações ou exclusões dos arquivos ("novo" ou "desaparecido", opcionalmente "+l" se for um link simbólico) e alterações do modo ("+x" ou "-x" para adicionar ou remover um bit executável, respectivamente) no diffstat. As informações são colocadas entre a parte do nome do arquivo e a parte do grafo. Implica no uso da opção --stat.

--numstat

Semelhante ao --stat, exibe a quantidade de linhas adicionadas, excluídas, em notação decimal e o nome do caminho sem abreviação, para torná-lo mais amigável à máquina. Para arquivos binários, gera dois - em vez de 0 0.

--shortstat

Produz apenas a última linha do formato --stat contendo a quantidade total dos arquivos modificados, assim como a quantidade de linhas adicionadas e excluídas.

-X[<parâmetro1,parâmetro2,…>]

--dirstat[=<parâmetro1,parâmetro2,…>]

Produz a distribuição da quantidade relativa de alterações para cada subdiretório. O comportamento do --dirstat pode ser customizado passando uma lista de parâmetros separados por vírgula. As predefinições são controlados pela variável de configuração diff.dirstat (veja git-config[1]). Os seguintes parâmetros estão disponíveis:

changes: Calcule os números "dirstat" contando as linhas que foram removidas da fonte ou adicionadas ao destino. Ignora a quantidade de movimentos de código puro em um arquivo. Em outras palavras, reorganizar as linhas em um arquivo não conta tanto quanto as outras alterações. Este é o comportamento predefinido quando nenhum parâmetro for utilizado.
lines: Calcule os números "dirstat" fazendo a análise diferencial com base nas linhas regulares e somando as contagens das linhas removidas / adicionadas. (Para os arquivos binários, conte em blocos de 64 bytes, pois os arquivos binários não têm um conceito natural de linhas). Este é um comportamento mais dispendioso do --dirstat do que o comportamento changes (alterações), conta as linhas reorganizadas em um arquivo tanto quanto as outras alterações. A produção resultante é consistente com o que você obtém das outras opções --*stat.
files: Calcule os números "dirstat" contando a quantidade de arquivos alterados. Cada arquivo alterado conta igualmente na análise do "dirstat". Este é o comportamento computacional mais barato do --dirstat, pois não precisa olhar o conteúdo do arquivo.
cumulative: Conta as alterações em um diretório herdeiro e também para o diretório de origem. Observe que, ao utilizar cumulative (cumulativo), a soma das porcentagens relatadas pode exceder os 100%. O comportamento predefinido (não cumulativo) pode ser especificado com o parâmetro noncumulative (não cumulativo).
<limite>: Um parâmetro inteiro especifica uma porcentagem de corte (a predefinição retorna para 3%). Os diretórios que contribuem com menos que esta porcentagem nas alterações não são exibidos na saída.

Exemplo: O seguinte contará os arquivos alterados, ignorando os diretórios com menos de 10% da quantidade total dos arquivos alterados e acumulando as contagens de um diretório-herdado nos diretórios-raiz: ---dirstat=arquivos,10,cumulative.

--cumulative

É um sinônimo para --dirstat=cumulative

--dirstat-by-file[=<parâmetro1,parâmetro2>…]

É um sinônimo para --dirstat=arquivos,parâmetro1,parâmetro2...

--summary

Produza um resumo condensado das informações estendidas do cabeçalho, como criações, renomeações e alterações do modo.

--patch-with-stat

É um sinônimo para -p --stat.

-z

Separe os commits com caracteres NUL em vez de novos caracteres "newlines" (novas linhas).

Além disso, quando a opção --raw ou --numstat for utilizado, não una os nomes dos caminhos e utilize caracteres NUL como terminadores na saída dos campos.

Sem esta opção, os nomes do caminho com caracteres "incomuns" são citados como explicado na variável de configuração core.quotePath (veja linkgit:git-config [1]).

--name-only

Exiba apenas os nomes dos arquivos que foram alterados.

--name-status

Exiba apenas os nomes e a condição atual dos arquivos que foram alterados. Consulte a descrição da opção --diff-filter sobre o significado das letras de condição.

--submodule[=<formato>]

Especifique como as diferenças nos submódulos são exibidos. Ao especificar --submodule=short, o formato short (curto) é utilizado. Este formato exibe apenas os nomes dos commits no início e no final do intervalo. Ao utilizar a opção --submodule ou --submodule=log, o formato log passa a ser utilizado. Este formato lista os commits no intervalo como o git-submodule[1] summary (resumo) faz. Ao utilizar a opção --submodule=diff, o formato diff passa a ser utilizado. Este formato exibe uma comparação nas linhas das alterações no conteúdo do submódulo entre o intervalo do commit. A predefinição retorna para a opção de configuração diff.submodule ou o formato short (curto) caso a opção da configuração estiver desativada.

--color[=<quando>]

Exibe o diff colorido. A opção --color (sem =<quando> por exemplo) é o mesmo que a opção --color=always. <quando> pode ser always (sempre), never (nunca), ou auto.

--no-color

Desativa o diff colorido. É o mesmo que --color=never.

--color-moved[=<modo>]

As linhas de código que foram movidas são coloridas de maneira diferente. O <modo> retorna para a predefinição como no caso a opção não seja utilizada e para zebra caso a opção seja utilizada sem nenhum modo. O modo deve ser um dos seguintes:

no: As linhas movidas não são destacadas.
default: É um sinônimo para zebra. Pode ser que isso mude para um modo mais sensível no futuro.
plain: Qualquer linha adicionada em um local e removida em outro será colorida com color.diff.newMoved. Da mesma forma, color.diff.oldMoved será utilizado para as linhas que forem removidas e que foram adicionadas em outro lugar no diff. Este modo seleciona qualquer linha movida, mas não é muito útil em uma revisão para determinar se um bloco do código foi movido sem permutação.
blocks: Os blocos de texto movidos com pelo menos 20 caracteres alfanuméricos são detectados de forma ávida. Os blocos detectados são pintados utilizando a cor color.diff.{old,new}Moved. Os blocos adjacentes não podem ser separados.
zebra: Os blocos de texto que foram movidos são detectados como no modo blocks (blocos). Os blocos são pintados utilizando a cor color.diff.{old,new}Moved ou color.diff.{old,new}MovedAlternative. A alteração entre as duas cores indica que um novo bloco foi detectado.
dimmed-zebra: Semelhante ao zebra, porém é realizado o escurecimento adicional das partes desinteressantes do código que foi movido. As linhas limítrofes dos dois blocos adjacentes são considerados como interessantes, o resto como não interessante. dimmed_zebra é um sinônimo obsoleto.

--no-color-moved

Desativa a detecção de movimento. Pode ser utilizado para substituir a definição da configuração. É o mesmo que --color-moved=no.

--color-moved-ws=<modos>

Configura como o espaço é ignorado durante a execução da detecção do mover para --color-moved. Estes modos podem ser utilizados como uma lista separada por vírgulas:

no: Não ignore os espaços quando realizar a detecção da ação de mover.
ignore-space-at-eol: Ignore as alterações no espaço na EOL (fim da linha).
ignore-space-change: Ignore as alterações na quantidade do espaço. Ignora o espaço no final da linha e considera todas as outras sequências de um ou mais caracteres de espaço como equivalentes.
ignore-all-space: Ignore o espaço durante a comparação das linhas. Ignore as diferenças mesmo que uma linha tenha espaços quando a outra linha não tiver nenhuma.
allow-indentation-change: Ignore inicialmente, qualquer espaço na detecção da ação de mover, em seguida, agrupe os blocos do código que foram movidos apenas em um bloco caso a alteração no espaço seja a mesma em cada linha. Isto é incompatível com os outros modos.

--no-color-moved-ws

Não ignore os espaços quando realizar a detecção da ação de mover. Pode ser utilizado para substituir a definição da configuração. É o mesmo que --color-moved-ws=no.

--word-diff[=<modo>]

Exiba umadiff entre as palavras, usando o <modo> para delimitar as palavras alteradas. É predefinido que as palavras sejam delimitadas por espaços; consulte --word-diff-regex abaixo. O <modo> retorna para a predefinição plain e deve ser um dos seguintes:

color: Destaque as palavras alteradas usando apenas as cores. Implica no uso da opção --color.
plain: Exiba as palavras como [-removed-] (removido) e {+added+} (adicionado). Não faz nenhuma tentativa de escapar os delimitadores caso eles apareçam na entrada, portanto, a saída pode ser ambígua.
porcelain: Use um formato especial orientado em linha destinado para a utilização com um script. As execuções adicionadas/removidas/inalteradas são impressas no formato diff unificado tradicional, começando com um caractere +/-/` ` no início da linha e estendendo-se até o final. As novas linhas na entrada são representadas por um til ~ em uma linha própria.
none: Desative a palavra diff novamente.

Observe que, apesar do nome do primeiro modo, a cor é utilizada para realçar as partes alteradas em todos os modos caso seja ativada.

--word-diff-regex=<expressão-regular>

Utilize uma <expressão-regular> para decidir o que uma palavra é em vez de considerar as execuções dos espaços que não estejam vazios como uma palavra. Também implica no uso da opção --word-diff, a menos que já esteja ativo.

Toda a coincidência não sobreposta do <expressão-regular> é considerado como sendo uma palavra. Qualquer coisa entre estas coincidências é considerada um espaço e é ignorado(!) com o objetivo de encontrar as diferenças. Você pode anexar |[^[:space:]] à sua expressão regular para garantir que ela coincida com todos os caracteres que não sejam espaços. Uma coincidência que contenha uma nova linha é silenciosamente truncada(!) na nova linha.

A opção --word-diff-regex=. por exemplo, tratará cada caractere como uma palavra e coincidentemente, exibirá as diferenças caractere a caractere.

A expressão regular também pode ser definida através de um controlador do diff ou uma opção de configuração, consulte gitattributes[5] or git-config[1]. A concessão explícita substitui qualquer controle diff ou uma configuração. Os controles diff substituem as definições da configuração.

--color-words[=<expressão-regular>]

Equivalente a --word-diff=color mais (caso um regex seja utilizado) --word-diff-regex=<expressão-regular>.

--no-renames

Desative a detecção da ação de renomear, mesmo quando o arquivo de configuração seja predefinido para tanto.

--[no-]rename-empty

Se usa ou não bolhas vazias como origem do nome.

--check

Avise caso as alterações introduzirem os marcadores de conflito ou os erros de espaço. A configuração core.whitespace define o que são considerados erros de espaço. É predefinido que os espaços à direita (incluindo as linhas que consistem apenas de espaços) e um caractere de espaço que seja imediatamente seguido por um caractere de tabulação dentro do recuo inicial da linha, são considerados erros de espaço. Encerra com uma condição diferente de zero caso problemas sejam encontrados. Não é compatível com --exit-code.

--ws-error-highlight=<tipo>

Destaque os erros de espaço nas linhas context (contexto), old (antigo) ou new (novo) do diff. Vários valores são separados por vírgula, none redefine os valores anteriores, default redefine a lista para new e all é uma abreviação para old,new,context. Quando esta opção não é utilizada e a variável de configuração diff.wsErrorHighlight não está definida, apenas os erros de espaço nas linhas novas são destacados. Os erros de espaço são coloridos com color.diff.whitespace.

--full-index

Em vez do primeiro punhado de caracteres, exiba os nomes completos dos objetos bolha antes e depois da imagem na linha "index" ao produzir a saída no formato patch.

--binary

Além de --full-index, gere um diff binário que possa ser aplicado com o comando git-apply. Implica no uso da opção --patch.

--abrev[=<n>]

Em vez de exibir o nome completo do objeto hexadecimal com 40 bytes na produção do formato diff-raw e nas linhas do cabeçalho da árvore diff, exiba apenas um prefixo parcial. Isso é independente da opção --full-index acima, que controla o formato da produção da saída do diff-patch. A quantidade de dígitos fora do preestabelecido pode ser especificado com a opção --abbrev=<n>.

-B[<n>][/<m>]

--break-rewrites[=[<n>][/<m>]]

Divida as alterações reescritas que foram completas em pares de exclusão e criação. Isso serve a dois propósitos:

Afeta a maneira como uma mudança que equivale a uma reescrita total de um arquivo, não como uma série de exclusão e inserção combinadas com poucas linhas que coincidem textualmente com o contexto, e sim como uma única exclusão de tudo o que é antigo seguido por um inserção única de tudo que for novo, o número m controla este aspecto da opção -B (a predefinição retorna para 60%). -B / 70% determina que menos de 30% do original deve permanecer no resultado para que o Git considere-o como uma reescrita total (ou seja, caso contrário, o patch resultante será uma série de exclusões e inserções combinados com linhas de contexto).

Quando utilizado com a opção -M, um arquivo totalmente reescrito também é considerado a fonte de uma renomeação (O -M geralmente considera apenas um arquivo que desapareceu como a origem de uma renomeação), o número n controla esse aspecto da opção -B (a predefinição retorna para 50%). O -B20% determina que uma alteração com a adição e a exclusão em comparação com 20% ou mais do tamanho do arquivo é elegível para ser selecionada como uma possível fonte de renomeação para um outro arquivo.

-M[<n>]

--find-renames[=<n>]

Ao produzir os diffs, detecte e relate tudo que for renomeado em cada commit. Para acompanhar os arquivos através das renomeações enquanto percorre o histórico consulte o comando --follow. Caso n seja utilizado, é a limítrofe do índice da similaridade (A quantidade de adições/exclusões comparado ao tamanho do arquivo). -M90% significa que o Git deve considerar uma ação do par de exclusão/adição para ser renomeado caso mais que 90% do arquivo não tenha sido alterado. Sem um sinal de %, a quantidade deve ser lida como uma fração, com um ponto decimal antes dele. -M5 se torna por exemplo 0.5, portanto, é o mesmo que -M50%. Da mesma forma que -M05 é o mesmo que -M5%. Para limitar a detecção para renomeações exatas, utilize -M100%. A predefinição para o índice de similaridade é 50%.

-C[<n>]

--find-copies[=<n>]

Detecte as cópias e também o que for renomeado. Consulte também --find-copies-harder. Caso n seja utilizado, ele terá o mesmo significado que -M<n>.

--find-copies-harder

Por motivos de desempenho, a predefinição retorna para que a opção -C encontre as cópias apenas caso o arquivo original da cópia tenha sido modificado no mesmo conjunto de alterações. Essa flag faz com que o comando inspecione os arquivos que não modificados como candidatos à origem da cópia. Esta é uma operação muito dispendiosa em projetos grandes, portanto, utilize-a com cuidado. Tem o mesmo efeito caso a opção -C seja repetida.

-D

--irreversible-delete

Omita a imagem prévia que será excluída, ou seja, imprima apenas o cabeçalho, mas não a diferença entre a pré-imagem e /dev/null. O patch resultante não deve ser aplicado com com o comando patch ou git apply; é apenas para pessoas que desejam se concentrar em revisar o texto após a alteração. Além disso, a saída obviamente não possui informações suficientes para aplicar esse patch em sentido inverso, mesmo manualmente, daí o nome da opção.

Quando utilizado em conjunto com a opção -B, omita também a pré-imagem na parte da exclusão de um par excluir/criar.

-l<num>

As opções -M e -C requerem um tempo de processamento O(n^2) em que n é a quantidade de possíveis alvos para renomeações/cópia. Esta opção impede que a detecção da ação de renomear/cópia seja executada se a quantidade dos alvos a serem renomeados/copiados exceda o a quantidade especificada.

--diff-filter=[(A|C|D|M|R|T|U|X|B)…[*]]

Selecione apenas os arquivos Adicionados (A), Copiados (C), Excluídos (D), Modificados (M), Renomeados (R) e que tenham o seu tipo (por exemplo, arquivo normal, link simbólico, o submódulo, …) alterado (T), não está mesclado (U), que seja desconhecido (X) ou que teve o seu emparelhamento quebrado (B). Qualquer combinação dos caracteres do filtro (incluindo none nenhum) pode ser utilizado. Quando * (Tudo ou nenhum) é adicionado à combinação, todos os caminhos são selecionados caso haja algum arquivo que coincida com outros critérios durante a comparação; caso não haja nenhum arquivo que coincida com outros critérios, nada será selecionado.

Além disso, estas letras maiúsculas podem ser transformadas em minusculas para se excluir. --diff-filter=ad exclui os caminhos adicionados e excluídos por exemplo.

Observe que nem todas as diferenças diff podem apresentar todos os tipos. Por exemplo, diffs do índice para a árvore de trabalho nunca podem ter entradas adicionadas (porque o conjunto dos caminhos inclusos no diff é limitado pelo que está no índice). Da mesma forma, as entradas copiadas e renomeadas não podem aparecer caso a detecção para estes tipos estiverem desativados.

-S<texto>

Procure por diferenças que alterem a quantidade de ocorrências da cadeia de caracteres especificada (ou seja, adição/exclusão) em um arquivo. Destinado ao uso do scripter.

Útil durante a produra por um bloco de código exato (como uma "struct"), e quera saber o histórico deste bloco desde que ele surgiu: utilize o recurso de forma iterativa para alimentar o bloco de interesse na pré-imagem de volta -S e continue até você obter a primeira versão do bloco.

Os arquivos binários também são pesquisados.

-G<expressão-regular>

Procure por diferenças cujo texto do patch contenha as linhas adicionadas/removidas que correspondam a um <expressão-regular>.

Para ilustrar a diferença entre -S<expressão-regular> --pickaxe-regex e -G<expressão-regular>, considere um commit com o seguinte diff no mesmo arquivo:

+    return frotz(nitfol, two->ptr, 1, 0);
...
-    hit = frotz(nitfol, mf2.ptr, 1, 0);

Enquanto o git log -G"frotz\(nitfol" exibirá este commit, já o git log -S"frotz\(nitfol" --pickaxe-regex não (porque a quantidade de ocorrências dessa cadeia de caracteres não foi alterada) .

A menos que --text seja utilizado, os patches dos arquivos binários sem um filtro "textconv" serão ignorados.

Para mais informações consulte a entrada pickaxe em gitdiffcore[7].

--find-object=<id-do-objeto>

Procure pelas diferenças que alteram a quantidade de ocorrências do objeto especificado. Similar ao -S, porém apenas o argumento é diferente pois ele não procura por uma sequência específica, mas por um ID específico do objeto.

O objeto pode ser uma bolha ou um commit do submódulo. Para também encontrar árvores, faça a utilização da opção -t também no git-log.

--pickaxe-all

Quando a opção -S ou -G encontra uma alteração, exiba todas as alterações naquele conjunto de alterações e não apenas nos arquivos que contenham as alterações em uma <texto>.

--pickaxe-regex

Trate o <texto> utilizado com o -S como uma expressão regular POSIX estendida para coincidir.

-O<ordem-do-arquivo>

Controlar a ordem em que os arquivos aparecem na saída. Substitui a variável de configuração diff.orderFile (consulte git-config[1]). Para cancelar a variável diff.orderFile, utilize -O/dev/null.

A ordem da saída é determinada pela ordem dos padrões bolha na <ordem-do-arquivo>. São enviados primeiro todos os arquivos cujos nomes do caminho coincidam com o primeiro padrão, em seguida todos os arquivos cujos nomes do caminho coincidam com o segundo padrão (mas não ao primeiro) e assim por diante. São exibidos por último todos os arquivos cujos nomes do caminho não coincidam com nenhum padrão como se houvesse um padrão de coincidência total implícito no final do arquivo. Caso vários nomes do caminho tenham a mesma classificação (eles coincidem com o mesmo padrão, mas não com os padrões anteriores), a sua ordem na saída em relação à outra é a ordem normal.

A <ordem-do-arquivo> é analisado da seguinte maneira:

As linhas em branco são ignoradas para que possam ser utilizadas como separadores, facilitando a leitura.
As linhas que começam com um hash ("#") são ignoradas para que possam ser utilizadas como comentários. Adicione uma barra invertida ("\") ao início do padrão caso ele comece com um hash.
Cada outra linha quem contenha um único padrão.

Os padrões têm a mesma sintaxe e semântica que os padrões utilizados para fnmatch(3) sem a flag FNM_PATHNAME, exceto que um nome do caminho também coincida com um padrão caso a remoção de qualquer quantidade dos componentes finais do nome do caminho coincida com o padrão. O padrão "foo*bar" coincide com "fooasdfbar" e "foo/bar/baz/asdf" mas não com "foobarx" por exemplo.

-R

Troque as duas entradas; isto é, exiba as diferenças do índice ou do arquivo no disco para o conteúdo da árvore.

--relative[=<caminho>]

--no-relative

Com esta opção, quando executado a partir de um subdiretório do projeto, pode-se dizer para excluir as alterações fora do diretório e exibir os nomes do caminho relativos a ele. Quando não estiver em um subdiretório (em um repositório simples por exemplo), é possível nomear em qual subdiretório tornar a saída relativa, utilizando um <caminho> como argumento. A opção --no-relative pode ser utilizada para contrapor ambas as opções de configuração diff.relative e a anterior --relative.

-a

--text

Trate todos os arquivos como texto.

--ignore-cr-at-eol

Ignore o retorno do carro no final da linha durante uma comparação.

--ignore-space-at-eol

Ignore as alterações no espaço na EOL (fim da linha).

-b

--ignore-space-change

Ignore as alterações na quantidade do espaço. Ignora o espaço no final da linha e considera todas as outras sequências de um ou mais caracteres de espaço como equivalentes.

-w

--ignore-all-space

Ignore o espaço durante a comparação das linhas. Ignore as diferenças mesmo que uma linha tenha espaços quando a outra linha não tiver nenhuma.

--ignore-blank-lines

Ignore as alterações cujas linhas estejam todas em branco.

--inter-hunk-context=<linhas>

Exiba o contexto entre as diferenças, até a quantidade de linhas especificada, fundindo assim as que estão próximas umas das outras. A predefinição retorna para diff.interHunkContext ou 0 caso a opção de configuração não esteja definida.

-W

--function-context

Exiba todas as funções ao redor das alterações.

--ext-diff

Permitir que um auxiliar diff externo seja executado. Caso um controlador diff externo seja definido com gitattributes[5], será necessário a utilização desta opção com git-log[1] e seus companheiros.

--no-ext-diff

Não permitir o uso de um controladores diff externo.

--textconv

--no-textconv

Permita (ou não permita) a execução dos filtros externos para a conversão do texto durante a comparação dos arquivos binários. Para mais detalhes consulte gitattributes[5]. Como os filtros "textconv" são normalmente uma conversão unidirecional, o diff resultante é legível para as pessoas porém não pode ser aplicado. Por este motivo, é predefinido que os filtros "textconv" estejam ativos apenas para os comandos git-diff[1] e git-log[1], mas não para os comandos git-format-patch[1] ou comandos "diff" que possam ser redirecionados.

--ignore-submodules[=<quando>]

Ignore as alterações nos submódulos durante a geração dos diffs. O <quando> pode ser "none" (nenhum), "untracked" (sem monitoramento/rastreamento), "dirty" (sujo) ou "all" (todos), que é a predefinição. O "none" considera o submódulo modificado quando houver arquivos não estejam rastreados, modificados ou o seu HEAD seja diferente do commit registrado no superprojeto, pode ser utilizado para substituir qualquer configuração da opção ignore (ignorar) em git-config[1] ou gitmodules[5]. Quando o "untracked" é utilizado, os submódulos não são considerados sujos quando houver apenas um conteúdo sem rastreamento (porém o monitoramento de alterações do seu conteúdo continua) O uso de "dirty" ignora todas as alterações na árvore de trabalho dos submódulos, apenas as alterações nos commits armazenados no superprojeto são exibidos (este era o comportamento anterior até a versão 1.7.0). O uso de "all" oculta todas as alterações nos submódulos.

--src-prefix=<prefixo>

Exiba o prefixo da origem utilizada em vez de "a/".

--dst-prefix=<prefixo>

Exiba o prefixo do destino utilizado em vez de "b/".

--no-prefix

Não exiba nenhum prefixo da origem ou destino.

--line-prefix=<prefixo>

Prefira um prefixo adicional em cada linha produzida.

--ita-invisible-in-index

É predefinido que as entradas adicionadas através do comando "git add -N" apareçam como uma cadeia de caracteres vazia existente com o comando "git diff" e um novo arquivo com "git diff --cached". Esta opção faz com que a entrada apareça como um novo arquivo no "git diff" e inexistente no "git diff --cached". Esta opção pode ser revertida com --ita-visible-in-index. Ambas as opções são experimentais e podem ser removidas no futuro.

Para uma explicação mais detalhada sobre estas opções comuns, consulte também gitdiffcore[7].

Gerando a correção em um formato texto com a opção `-p`

Executando git-diff[1], git-log[1], git-show[1], git-diff-index[1], git-diff-tree[1], ou git-diff-files[1] com a opção -p produz um patch em formato texto. É possível personalizar a criação do patch em um formato texto através das variáveis de ambiente GIT_EXTERNAL_DIFF e GIT_DIFF_OPTS.

O que a opção -p produz é um pouco diferente do formato diff tradicional:

Ele é precedido por um cabeçalho "git diff" que se parece com:
```
diff --git a/arquivo1 b/arquivo2
```
Os nomes dos arquivos a/ e b/ são os mesmos a menos que haja uma renomeação ou cópia. Especialmente para uma criação ou exclusão, /dev/null não é utilizado no lugar dos nomes do arquivo a/ ou b/.

Quando há um envolvimento no processo de renomear ou copiar, arquivo1 e arquivo2 exibem o nome do arquivo de origem da renomeação ou cópia e o nome do arquivo produzido pela renomeação ou copia respectivamente.
É seguido por uma ou mais linhas estendidas do cabeçalho:
```
modo antigo               <modo>
modo novo                 <modo>
modo de arquivo excluído  <modo>
novo modo de arquivo      <modo>
copiar de                 <caminho>
copiar para               <caminho>
renomear de               <caminho>
renomear para             <caminho>
índice de similaridade    <quantidade>
índice de dissimilaridade <quantidade>
índice                    <hash>..<hash> <modo>
```
Os modos dos arquivo são impressos como números octais com 6 dígitos, incluindo o tipo do arquivo e dos bits de permissão do arquivo.

Os nomes do caminho nos cabeçalhos estendidos não incluem os prefixos a/ e b/.

O índice de similaridade é a porcentagem das linhas inalteradas e o índice de dissimilaridade é a porcentagem das linhas alteradas. É um número inteiro arredondado, seguido por um sinal de porcentagem. O valor do índice de similaridade de 100% é reservado para dois arquivos iguais, enquanto a dissimilaridade de 100% significa que nenhuma linha do arquivo antigo chegou ao novo.

A linha do índice inclui os nomes dos objetos bolha antes e depois da alteração. O <modo> será incluído caso o modo do arquivo não seja alterado; caso contrário, linhas separadas indicam o modo antigo e o novo.
Os nomes dos caminhos com caracteres "incomuns" são citados como já explicado na variável de configuração core.quotePath (consulte git-config[1]).
Todos os arquivos arquivo1 na saída se referem aos arquivos antes do commit e todos os arquivos arquivo2 se referem aos arquivos após o commit. É incorreto aplicar cada alteração em cada arquivo sequencialmente. Por exemplo, este patch irá substituir a e b:
```
diff --git a/a b/b
renomeie a partir de a
renomeie para b
diff --git a/b b/a
renomeie a partir do b
renomeie para a
```

O formato diff combinado

Qualquer comando que gere um diff pode utilizar a opção -c ou --cc para produzir um diff combinado ao exibir uma mesclagem. Este é o formato predefinido durante a exibição das mesclagens com git-diff[1] or git-show[1]. Observe também que é possível utilizar a opção -m com qualquer um destes comandos para impor a geração dos diffs com as origens individuais de uma mesclagem.

Um formato "diff combinado" fica assim:

diff --combined describe.c
index fabadb8,cc95eb0..4866510
--- a/describe.c
+++ b/describe.c
@@@ -98,20 -98,12 +98,20 @@@
	return (a_date > b_date) ? -1 : (a_date == b_date) ? 0 : 1;
  }

- static void describe(char *arg)
 -static void describe(struct commit *cmit, int last_one)
++static void describe(char *arg, int last_one)
  {
 +	unsigned char sha1[20];
 +	struct commit *cmit;
	struct commit_list *list;
	static int initialized = 0;
	struct commit_name *n;

 +	if (get_sha1(arg, sha1) < 0)
 +		usage(describe_usage);
 +	cmit = lookup_commit_reference(sha1);
 +	if (!cmit)
 +		usage(describe_usage);
 +
	if (!initialized) {
		initialized = 1;
		for_each_ref(get_name);

Ele é precedido por um cabeçalho "git diff" parecido com este (quando a opção -c é utilizada):
```
diff --combined arquivo
```
ou assim (quando a opção --cc é utilizada):
```
diff --cc arquivo
```
Ele é seguido por uma ou mais linhas estendidas do cabeçalho (este exemplo exibe uma mesclagem com duas origens):
```
índice <hash>,<hash>..<hash>
modo <modo>,<modo>..<modo>
modo novo arquivo <modo>
modo arquivo excluído <modo>,<modo>
```
A linha modo <modo>,<modo>..<modo> aparece apenas caso pelo menos um dos <modos> seja diferente do restante. Os cabeçalhos estendidos com informações sobre a movimentação do conteúdo detectado (renomeação e detecção da cópia) são projetados para trabalhar com o diff com dois <tree-ish> e não são utilizados pelo formato diff combinado.
É seguido por duas linhas do cabeçalho do arquivo/para o arquivo
```
--- a/arquivo
+++ b/arquivo
```
Semelhante ao cabeçalho de duas linhas para o formato diff tradicional unificado, o /dev/null é utilizado para sinalizar os arquivos criados ou excluídos.

No entanto, caso a opção --combined-all-paths seja utilizada, em vez de duas linhas do arquivo/para o arquivo, será obtido um cabeçalho N+1 do cabeçalho do arquivo de "origem" para o arquivo de "destino" onde N é a quantidade de origens na mesclagem do commit
```
--- a/arquivo
--- a/arquivo
--- a/arquivo
+++ b/arquivo
```
Este formato estendido pode ser útil caso a detecção da renomeação ou cópia esteja ativa, permitindo que você veja o nome original do arquivo em diferentes origens.
O formato do cabeçalho do pedaço é modificado para prevenir que as pessoas o alimentem acidentalmente com patch -p1. O formato diff combinado foi criado para revisar as alterações da mesclagem dos commits e não era para ser aplicado. A alteração é semelhante a alteração no cabeçalho estendido do índice:
```
@@@ <from-file-range> <from-file-range> <to-file-range> @@@
```
Existem (a quantidade de origens + 1) caracteres @ no cabeçalho do bloco para o formato diff combinado.

Diferente do formato diff unificado tradicional que exiba os dois arquivos A e B com uma única coluna que possua o sinal de menos - (o sinal de menos — aparece em A mas é removido em B), + (o sinal de mais — ausente em A, mas adicionado em B), ou o prefixo " " (sem alteração — de espaço), este formato compara dois ou mais arquivos arquivo1, arquivo2, … com um arquivo X e exibe como X difere de cada arquivoN. Uma coluna para cada arquivoN é anexada à linha de saída para observar como a linha de X é diferente dela.

Um caractere - na coluna N significa que a linha aparece no "arquivoN", mas não aparece no resultado. Um caractere + na coluna N significa que a linha aparece no resultado e o arquivoN não possui essa linha (em outras palavras, a linha foi adicionada, do ponto de vista dessa origem).

Na saída do exemplo acima, a assinatura da função foi alterada nos dois arquivos (portanto, duas remoções - do arquivo1 e do arquivo2, mais ++ significa que uma linha que foi adicionada não aparece no arquivo1 ou no arquivo2). Outras oito linhas também são iguais no arquivo1, mas não aparecem no arquivo2 (portanto, prefixadas com +).

Quando exibido pelo comando git diff-tree -c, compara as origens de um commit mesclado com o resultado da mesclagem (ou seja, arquivo1..arquivoN são as origens). Quando exibido pelo comando git diff-files -c, as duas origens com as suas respectivas mesclagens não resolvidas com o arquivo da árvore de trabalho (ou seja, arquivo1 é o estágio 2, informado como "nossa versão", o arquivo2 é o estágio 3, informado como "a versão deles").

EXEMPLOS

git show v1.0.0: Exibe a tag v1.0.0 junto com o objeto que as tags apontarem.
git show v1.0.0^{tree}: Exibe a árvore apontada pela tag v1.0.0.
git show -s --format=%s v1.0.0^{commit}: Exiba o assunto do commit apontado pela tag v1.0.0.
git show next~10:Documentation/README: Exibe o conteúdo do arquivo Documentation/README como eles estavam atualmente no décimo último commit do ramo next.
git show master:Makefile master:t/Makefile: Concatena o conteúdo dos referidos Makefiles no HEAD do ramo master.

DISCUSSÃO

O Git é, até certo ponto, um codificador de caracteres agnóstico.

O conteúdo dos objetos blob são sequências de bytes não interpretados. Não há tradução de codificação no nível principal.
Os nomes do caminho são codificados na forma de normalização UTF-8 C. Isso se aplica a objetos nas árvore, arquivos do índice, referência de nomes e nomes do caminho em argumentos da linha de comando, variáveis do ambiente e os arquivos de configuração (.git / config (consulte git-config[1]), gitignore[5], gitattributes[5] e gitmodules[5]).

Observe que o Git em seu nível básico trata os nomes dos caminhos simplesmente como sequências de bytes não NUL, não há conversões de codificação dos nomes dos caminhos (exceto no Mac e no Windows). Portanto, o uso dos nomes do caminhos que não sejam ASCII funcionará principalmente em plataformas e sistemas de arquivos que se utilizem de codificações ASCII estendidas e herdadas. No entanto, os repositórios criados nestes sistemas não funcionarão corretamente em sistemas baseados em UTF-8 (por exemplo, Linux, Mac, Windows) e vice-versa. Além disso, muitas ferramentas baseadas em Git simplesmente assumem nomes do caminho como UTF-8 e falharão ao exibir outros tipos de codificações corretamente.
As mensagens do registro log do commit geralmente são codificadas em UTF-8, porém há compatibilidade para outras codificações ASCII estendidas. Isso inclui ISO-8859-x, CP125x e muitos outros. Porém não há compatibilidade com codificações UTF-16/32, EBCDIC e CJK, codificações de vários bytes (GBK, Shift-JIS, Big5, EUC-x, CP9xx etc.).

Embora incentivemos que as mensagens do registro log do commit sejam codificadas em UTF-8, a Porcelana do Git e seu núcleo foram projetados para não impor a utilização do UTF-8 nos projetos. Caso todos os participantes de um projeto em particular achem mais conveniente usar as codificações herdadas, o Git não o proibirá. Porém, há algumas coisas a serem consideradas.

Ambos os comandos git commit" e "git commit-árvore emitem um aviso caso a mensagem do registro log do commit utilizada não se parecer com uma string UTF-8 válida, a menos que explicitamente queira que seu projeto utilize uma codificação do legado. A melhor maneira de usar isso é ter uma variável i18n.commitencoding em um arquivo .git/config, como este:
```
[i18n]
	commitEncoding = ISO-8859-1
```
Os objetos commit que foram criados com a configuração acima registram o valor i18n.commitEncoding em seu cabeçalho encoding. Isso é para auxiliar as outras pessoas que olharão para eles mais tarde. A falta deste cabeçalho implica que a mensagem do registro log do commit seja codificado em UTF-8.
Os comandos git log, git show, git blame e relacionados fazem vista para o cabeçalho encoding de um objeto commit e tentam codificar novamente a mensagem do registro log em UTF-8 a menos que seja definido de outra maneira. É possível especificar a codificação da saída desejada com a variável i18n.logOutputEncoding no arquivo .git/config, assim:
```
[i18n]
	logOutputEncoding = ISO-8859-1
```
Caso não tenha essa variável de configuração, o valor de i18n.commitEncoding é utilizado em seu lugar.

Observe que decidimos deliberadamente não codificar novamente a mensagem do registro log do commit quando um commit for feito para forçar a codificação UTF-8 a nível do objeto commit, porque a re-codificação para UTF-8 não é necessariamente uma operação reversível.

Parte do conjunto git[1]

Setup and Config

Getting and Creating Projects

Basic Snapshotting

Branching and Merging

Sharing and Updating Projects

Inspection and Comparison

Patching

Debugging

Email

External Systems

Server Admin

Guides

Administration

Plumbing Commands