Git

git-log last updated in 2.46.0

NOME

git-log - Exibe os registros log do commit

RESUMO

git log [<opções>] [<intervalo-das-revisões>] [[--] <caminho>…]

DESCRIÇÃO

Exibe os registros log do commit.

Liste os commits que podem ser acessados seguindo os links parent do(s) commit(s) mencionado(s), mas exclua os commits que podem ser acessados a partir do(s) commit(s) mencionado(s) com um ^ na frente deles. É predefinido que a saída é fornecida em ordem cronológica inversa.

Você pode pensar nisso como uma operação de conjunto. Os commits acessíveis a partir de qualquer um dos commits fornecidos na linha de comando formam um conjunto e, em seguida, os commits acessíveis a partir de qualquer um dos fornecidos com ^ na frente são subtraídos desse conjunto. Os commits restantes são o que aparece na saída do comando. Várias outras opções e parâmetros de caminhos podem ser usados para limitar ainda mais o resultado.

Assim, o seguinte comando:

$ git log foo bar ^baz

significa "listar todos os commits acessíveis a partir do foo ou bar, porém não de baz".

Uma notação especial "<commit1>..<commit2>" pode ser usada como uma abreviação para "^<commit1> <commit2>". Por exemplo, qualquer um dos seguintes podem ser usados de forma intercambiável:

$ git log origin..HEAD
$ git log HEAD ^origin

Outra notação especial é "<commit1>…<commit2>", que é útil para as mesclagens. O conjunto dos commits resultante é a diferença simétrica entre os dois operandos. Os dois comandos a seguir são equivalentes:

$ git log A B --not $(git merge-base --all A B)
$ git log A...B

O comando aceita as opções aplicáveis ao comando git-rev-list[1] para controlar o que é exibido e como. As opções aplicáveis ao comando git-diff[1] serve para controlar como as alterações que cada commit faz são exibidas.

OPÇÕES

--follow

Continue listando o histórico de um arquivo além de o renomear (funciona apenas para um único arquivo).

--no-decorate

--decorate[=short|full|auto|no]

Imprima os nomes de referência de todos os commits exibidos. Se short for usado, os prefixos de nome de referência refs/heads/, refs/tags/ e refs/remotes/ não serão impressos. Se full for usado , o nome completo da referência (incluindo o prefixo) será impresso. Se auto for usado, se a saída estiver indo para um terminal, os nomes de referência serão mostrados como se short tivesse sido usado; caso contrário, nenhum nome de referência será mostrado. A opção --decorate é um atalho para --decorate=short. Se configurado é a predefinição para o valor de configuração de log.decorate; caso contrário, auto.

--decorate-refs=<padrão>

--decorate-refs-exclude=<padrão>

Para cada referência de candidato, não o use para decoração caso ele coincida com algum padrão fornecido para a opção --decorate-refs-exclude ou caso não coincida com nenhum padrão fornecido para --decorate-refs. A opção de configuração log.excludeDecoration permite excluir as refs das decorações, porém um padrão explícito --decorate-refs será substituida caso coincida com log.excludeDecoration.

Caso nenhuma destas opções ou configurações sejam fornecidas, as referências serão usadas como decoração caso coincidam com HEAD, refs/heads/, refs/remotes/, refs/stash/ ou refs/tags /.

--clear-decorations

Quando definido, esta opção limpa todas as opções anteriores --decorate-refs ou --decorate-refs-exclude e relaxa o filtro padrão de decoração para incluir todas as referências. Esta opção é assumida caso o valor de configuração log.initialDecorationSet seja definida como all.

--source

Exiba na tela o nome "ref" utilizado na linha de comando pela qual cada commit foi alcançado.

--[no-]mailmap

--[no-]use-mailmap

Utilize o arquivo mailmap para mapear os nomes dos autores dos commits e seus endereços de e-mail para nomes e endereços de e-mail reais canônicos. Consulte git-shortlog[1].

--full-diff

Sem esta opção, o git log -p <caminho>... mostra os commits que tocam os caminhos especificados e os diffs sobre os mesmos caminhos especificados. Com isso, o diff completo é mostrado para os commits que tocam os caminhos especificados; isso significa que "<caminho>…" limita apenas os commits e não limita o diff para estes commits.

Observe que isso afeta todos os tipos de saída baseados em "diff", por exemplo os produzidos pelas opções --stat, etc.

--log-size

Inclua uma linha “log size <número>” na saída para cada commit, onde <número> é o tamanho da mensagem deste commit em bytes. Destina-se a acelerar as ferramentas que leem mensagens de registro da saída do comando git log, permitindo que elas aloquem espaço antecipadamente.

-L<inicio>,<fim>:<arquivo>

-L:<nome-da-função>:<arquivo>

Rastreia a evolução do intervalo das linhas que foram mencionados por <inicio>,<fim> ou pelo nome da função regex <funcname>, dentro do <arquivo>. Você não pode fornecer nenhum limitador pathpec. Atualmente, isso está limitado a uma caminhada a partir de uma única revisão, ou seja, você só pode fornecer zero ou um argumento positivo de revisão, e <inicio> e <fim> (ou <funcname>) devem existir na revisão inicial. Você pode especificar esta opção mais de uma vez. Implica no uso da opção --patch. A geração das correções (patch) pode ser suprimida com o uso de da opção --no-patch, mas outros formatos diff (como --raw, --numstat, --shortstat, --dirstat, --summary, --name-only, --name-status, --check) não estão implementados no momento.

<inicio> e <fim> podem assumir uma destas formas:

número

Caso <inicio> ou <fim> seja um número, ele especifica um número de linha absoluto (as linhas contam a partir do 1).
/regex/

Este formulário usará a primeira linha que corresponder ao regex POSIX informado. Se <inicio> for um regex, ele pesquisará a partir do final do intervalo -L anterior, se houver, caso contrário, a partir do início do arquivo. Se <inicio> for um ^/regex/, ele pesquisará a partir do início do arquivo. Se <fim> for um regex, ele pesquisará a partir da linha indicada por <inicio>.
+offset ou -offset

Válido apenas para <fim> que definirá uma quantidade de linhas antes ou depois da linha utilizada por <inicio>.

Caso :<funcname> seja informado no lugar do <inicio> e <fim>, é uma expressão regular que indica o intervalo da primeira <funcname> que coincida com <funcname> até a próxima linha funcname. :<funcname> pesquisa no final do intervalo -L anterior, se houver, caso contrário, a pesquisa ocorrerá desde o início do arquivo. ^:<funcname> pesquisa desde o início do arquivo. Os nomes das funções são determinados da mesma maneira que o comando git diff lida com os pedaços dos cabeçalhos do patch (consulte Definindo um cabeçalho personalizado do hunk em gitattributes[5]).

<revisão-faixa>: Mostra apenas os commits no intervalo de revisão especificado. Quando nenhum <faixa-da-revisão> é especificada, a predefinição é HEAD (ou seja, todo o histórico que leva ao commit atual). origin..HEAD especifica todos os commits acessíveis a partir do commit atual (ou seja, HEAD), mas não a partir de origin. Para obter uma lista mais completa de maneiras de soletrar <faixa-da-revisão>, consulte a seção "Especificando intervalos" de gitrevisions[7].
[--] <caminho>…: Mostra apenas os commits que são suficientes para explicar como os arquivos que coincidam com determinados caminhos foram criados. Consulte "Simplificação do histórico" abaixo para obter detalhes e outros modos de simplificação.

Os caminhos podem precisar ser prefixados com um -- para separá-los das opções ou do intervalo de revisões, quando um conflito surgir.

Limitação do Commit

Além de especificar uma série de commits que devem ser listados utilizando as notações especiais explicadas na descrição, podem ser aplicadas limitações adicionais ao commit.

O uso de mais opções geralmente limita ainda mais a saída (por exemplo, --since=<date1> limita os commits mais recentes do que <date1>, e ao usá-lo com --grep=<pattern> limita ainda mais os commits cuja mensagem de registro tenha uma linha que corresponda a <padrão>), a menos que seja indicado o contrário.

Observe que eles são aplicados antes da organização do commit e das opções de formatação como --reverse.

-<quantidade>

-n <quantidade>

--max-count=<quantidade>

Limita a quantidade de commits na saída.

--skip=<quantidade>

Ignora a 'quantidade’de commits antes começa a exibir a saída do commit.

--since=<data>

--after=<data>

Exiba os commits com data mais recente das que foram informada.

--since-as-filter=<data>

Mostra todos os commits mais recentes do que uma determinada data. Isso avalia todos os commits que estejam neste intervalo, em vez de parar no primeiro commit que for o mais antigo que uma determinada data.

--until=<data>

--before=<data>

Exiba os commits mais antigos com data mais antiga das que foram informada.

--author=<padrão>

--committer=<padrão>

Limite a saída dos commits àqueles com linhas de cabeçalho do autor/aque que fez o commit que correspondam ao padrão especificado (expressão regular). Com mais de um --author=<padrão>, os commits cujo autor corresponda a qualquer um dos padrões fornecidos são escolhidos (da mesma maneira para vários --committer=<padrão>).

--grep-reflog=<padrão>

Limite a saída dos commits àqueles com entradas de reflog que correspondam ao padrão especificado (expressão regular). Com mais de um --grep-reflog, são escolhidos os commits cuja mensagem de reflog corresponda a qualquer um dos padrões fornecidos. É um erro usar essa opção, a menos que a opção --walk-reflogs esteja em uso.

--grep=<padrão>

Limite a saída dos commits àqueles com uma mensagem de registro que corresponda ao padrão especificado (expressão regular). Com mais de um --grep=<padrão>, os commits cuja mensagem corresponda a qualquer um dos padrões fornecidos são escolhidos (porém, consulte a opção --all-match).

Quando --notes está em vigor, a mensagem das anotações é coincidida como se fizesse parte da mensagem do registro log.

--all-match

Limita a saída dos commits para aqueles que coincidam com todos os comandos --grep utilizado, em vez daqueles que coincidam com apenas um.

--invert-grep

Limita a saída dos commits para aqueles com uma mensagem de um registro log que não coincida com o padrão utilizado em com o comando --grep=<padrão>.

-i

--regexp-ignore-case

Coincida a expressão regular limitando o padrão sem considerar o tamanho das letras.

--basic-regexp

Considere os padrões limitadores como expressões regulares básicas; Essa é a predefinição.

-E

--extended-regexp

Considere os padrões de limitação a serem estendidos nas expressões regulares em vez das expressões regulares básicas predefinidas.

-F

--fixed-strings

Considere os padrões limitadores como cadeias de caracteres fixos (não interprete o padrão como uma expressão regular).

-P

--perl-regexp

Considere os padrões limitadores como expressões regulares compatíveis com o Perl.

A compatibilidade para estes tipos de expressões regulares é uma dependência opcional no momento da compilação. Caso o Git não tenha sido compilado com este suporte, o Git será encerrado caso esta opção seja utilizada.

--remove-empty

Pare quando um caminho informado tenha desaparecido da árvore.

--merges

Exiba apenas os commits que foram mesclados. É exatamente o mesmo que a opção --min-parents=2.

--no-merges

Não imprima os commits com mais de um pai. É exatamente o mesmo que a opção --max-parents=1.

--min-parents=<quantidade>

--max-parents=<quantidade>

--no-min-parents

--no-max-parents

Mostra apenas os commits que tenham pelo menos (ou no máximo) esta quantidade principal de commits. Em particular, a opção --max-parents=1 é o mesmo que --no-merges, já a opção --min-parents=2 é o mesmo que --merges. --max-parents=0 fornece todos os commits raiz e --min-parents=3 todas as mesclagens Octopus.

--no-min-parents e --no-max-parents redefinem estes limites (para nenhum limite) novamente. As formas equivalentes são --min-parents=0 (qualquer commit tem 0 ou mais ramos principais) e --max-parents=-1 (números negativos denotam que não há limite superior).

--first-parent

Ao encontrar os commits para serem inclusos, siga apenas o primeiro commit principal ao ver a mesclagem de um commit. Esta opção pode fornecer uma melhor visão geral ao visualizar a evolução de um ramo de tópico específico, porque as mesclagens no tópico de um ramo tendem a se ajustar apenas ao topo atualizado de tempos em tempos, e essa opção permite que você ignore os commits individuais trazidos ao seu histórico por essa mesclagem.

Esta opção também muda o formato diff padrão para a mesclagem dos commits para first-parent, consulte --diff-merges=first-parent para mais detalhes.

--exclude-first-parent-only

Ao encontrar os commits que serão excluídos (com um ^), siga apenas o primeiro commit principal ao ver a mesclagem de um commit. Isso pode ser usado para localizar um conjunto de alterações no tópico de num ramo a partir do ponto onde ele divergiu do ramo remoto, uma vez que mesclas arbitrárias podem ser alterações válidas no tópico do ramo.

--not

Inverte o significado do prefixo ^ (ou a falta dele) para todos os especificadores de revisão seguintes, até o próximo --not. Quando usado na linha de comando antes de --stdin, as revisões passadas por stdin não serão afetadas por ele. Por outro lado, quando encaminhadas pela entrada predefinida, as revisões passadas na linha de comando não serão afetadas por ela.

--all

Finja como se todos os refs em refs/ junto com HEAD estejam listados na linha de comando como <commit>.

--branches[=<padrão>]

Finja como se todas as refs no refs/heads estejam listadas na linha de comando como <commit>. Caso <padrão> seja utilizado, limite os ramos para aqueles que coincidam com a "shell blob" informada. Caso o padrão não tenha ?, *, ou '[, /* no final é implícito.

--tags[=<padrão>]

Finja como se todas as refs no refs/remotes estejam listados na linha de comando como <commit>. Caso <padrão> seja utilizado, limite os ramos para aqueles que coincidam com a "shell blob" informada. Caso o padrão não tenha ?, *, ou [, /* no final é implícito.

--remotes[=<padrão>]

Finja que todas as refs em refs/remotes estão listadas na linha de comando como <commit>. Se o <padrão> for fornecido, limita o rastreamento das ramificações remotas àquelas que correspondam ao glob do shell informado. Se o padrão não tiver ?, * ou [, /* no final, então ficará implícito.

--glob=<glob-pattern>

Finja como se todos as refs coincidentes com "shell glob" <glob-pattern> estejam listados na linha de comando como <commit>. A refs/ principal é anexada automaticamente caso esteja ausente. Caso o padrão não tenha ?, *, ou [, /* no final é implícito.

--exclude=<glob-pattern>

Não inclua as refs que coincidam com <glob-pattern> em que as próximas opções --all, --branches, --tags, --remotes ou --glob considerariam de outra forma. As repetições destas opções acumulam padrões de exclusão até a próxima opção --all, --branches, --tags, --remotes ou --glob (outras opções ou argumentos não limpam os padrões acumulados).

Os padrões informados não devem começar com refs/heads, refs/tags, ou refs/remotes quando aplicadas as opções --branches, --tags, ou --remotes respectivamente, e devem começar com refs/ quando for aplicado ao --glob ou --all. Se a intenção for um delimitador /*, este deve ser utilizado de forma explicita.

--exclude-hidden=[fetch|receive|uploadpack]

Não inclua refs que seriam ocultados por git-fetch, git-receive-pack ou git-upload-pack durante a consulta da configuração apropriada de fetch.hideRefs, receive.hideRefs ou uploadpack.hideRefs junto com transfer.hideRefs (consulte git-config[1]). Esta opção afeta a próxima opção pseudo-ref --all ou --glob e é zerada após o processamento.

--reflog

Finja que todos os objetos mencionados pelos reflogs estejam listados na linha de comando como <commit>.

--alternate-refs

Faça de conta que todos os objetos mencionados como dicas de referência de repositórios alternativos foram listados na linha de comando. Um repositório alternativo é qualquer repositório cujo diretório de objetos esteja especificado em objects/info/alternates. O conjunto de objetos incluídos pode ser modificado por core.alternateRefsCommand, etc. Consulte git-config[1].

--single-worktree

É predefinido que todas as árvores de trabalho serão examinadas através das seguintes opções quando houver mais de uma (consulte git-worktree[1]): --all, --reflog e --indexed-objects. Esta opção impõem que o exame seja feito apenas na árvore de trabalho atual.

--ignore-missing

Ao ver um nome de objeto inválido na entrada, finja que a entrada incorreta não foi informada.

--bisect

Finja como se uma bisseção ruim "ref" refs/bisect/bad estivesse listada e como se fosse seguida por --not e a boa bisseção refs refs/bisect/good-* na linha de comando.

--stdin

Além de obter argumentos da linha de comando, leia-os também da entrada padrão. Isso faz aceitar commits e pseudo-opções como --all e --glob=. Quando um separador -- é visto, a próxima entrada é tratada como caminhos e usada para limitar o resultado. Sinalizadores como --not, que são lidos por meio da entrada padrão, são respeitados apenas com argumentos passados da mesma forma e não influenciarão nenhum argumento subsequente da linha de comando.

--cherry-mark

Como --cherry-pick (veja abaixo), porém marque os commits equivalentes com = ao invés de omiti-los e equivalentes com +.

--cherry-pick

Omitir qualquer commit que apresente a mesma alteração como em outro commit do ``outro lado" quando o conjunto de commits são limitadas com diferença simétrica.

Como por exemplo, caso você tenha dois ramos, A e B, uma maneira comum de listar todos os commits em apenas um lado deles é com a opção --left-right (veja o exemplo abaixo na descrição da opção --left-right). No entanto, exibe os commits que foram selecionados de forma seletiva no outro ramo (por exemplo, “3º no b” pode ser a escolha seletiva do ramo A). Com esta opção, estes pares de commits são excluídos da saída.

--left-only

--right-only

Liste apenas os commits nos respectivos lados de um "diff" simétrico, ou seja, apenas aqueles que seriam marcados como < resp. > por --left-right.

Por exemplo, a opção --cherry-pick --right-only A...B omite os commits de B que estão em A ou são equivalentes a um patch de um commit em A. Em outras palavras, isso lista os commits + do git cherry A B. Mais precisamente, as opções --cherry-pick --right-only --no-merges fornece a lista exata.

--cherry

Um sinônimo para --right-only --cherry-mark --no-merges; útil para limitar a saída dos commits do nosso lado e marcar aqueles que forem marcados no histórico bifurcado do outro lado com git log --cherry upstream...meu-ramo, semelhante ao git cherry upstream meu-ramo.

-g

--walk-reflogs

Em vez de percorrer a cadeia de ancestralidade do commit, percorra as entradas do reflog desde a mais recente até as mais antigas. Quando esta opção é usada, você não pode especificar commits que serão excluídos (ou seja, as notações ^commit, commit1..commit2 e commit1...commit2 não podem ser usadas).

With --pretty format other than oneline and reference (for obvious reasons), this causes the output to have two extra lines of information taken from the reflog. The reflog designator in the output may be shown as ref@{<Nth>} (where <Nth> is the reverse-chronological index in the reflog) or as ref@{<timestamp>} (with the <timestamp> for that entry), depending on a few rules:

If the starting point is specified as ref@{<Nth>}, show the index format.
Caso o ponto inicial seja utilizado como ref@{now}, exiba o formato do registro de data e hora.
Caso nenhum deles tenha sido utilizado, mas a opção --date foi utilizado na linha de comando, exibe o registro de data e hora no formato solicitado por --date.
Caso contrário, exibe o formato do índice.

Em --pretty=oneline, a mensagem do commit é prefixada com essas informações na mesma linha. Esta opção não pode ser combinada com a opção --reverse. Consulte também o comando git-reflog[1].

Esta informação não será exibida de forma alguma sob --pretty=reference.

--merge

Show commits touching conflicted paths in the range HEAD...<other>, where <other> is the first existing pseudoref in MERGE_HEAD, CHERRY_PICK_HEAD, REVERT_HEAD or REBASE_HEAD. Only works when the index has unmerged entries. This option can be used to show relevant commits when resolving conflicts from a 3-way merge.

--boundary

O limite da exclusão dos commits que forem gerados. Os limites entre os commits são prefixados com -.

Simplificação do histórico

Às vezes, você está interessado apenas nas partes do histórico, por exemplo, os commit que alteraram um determinado <caminho>. Porém existem duas partes da Simplificação do Histórico, uma parte é a seleção dos commits e a outra é como fazê-lo, pois existem várias estratégias para simplificar o histórico.

As seguintes opções selecionam os commits que serão exibidos:

<caminhos>: São selecionados os commits que alterarem os <caminhos> informados.
--simplify-by-decoration: São selecionados os commits utilizados como referência por algumas ramificações ou tags.

Observe que os commits extras podem ser exibidos para fornecer um histórico significativo.

As seguintes opções afetam a maneira como a simplificação é feita:

Modo predefinido: Simplifique o histórico para o mais simples, explicando a condição final da árvore. Mais simples, porque elimina algumas ramificações laterais caso o resultado final for o mesmo (ou seja, mescle os ramos com o mesmo conteúdo)
--show-pulls: Inclua todas os commits no modo predefinido, porém também qualquer commits mesclado que não sejam TREESAME para o primeiro parente, porém sejam TREESAME para um parente posterior. Este modo auxilia na exibição do commit mesclado que "introduziu primeiro" a alteração em um ramo.
--full-history: O mesmo que o modo predefinido, mas não corta parte do histórico.
--dense: Apenas os commits selecionados são exibidos e mais alguns que tenham algum histórico significante.
--sparse: São exibidos todos os commits com um histórico simplificado.
--simplify-merges: Opção adicional para --full-history para remover algumas mesclagens desnecessárias do histórico resultante, pois não há commits selecionados contribuindo para essa mesclagem.
--ancestry-path[=<commit>]: Quando for dado um intervalo de commits a serem exibidos (por exemplo, commit1..commit2 ou commit2 ^commit1), exiba apenas os commits neste intervalo que sejam ancestrais do <commit>, descendentes do <commit> ou o próprio <commit>. Se nenhum commit for especificado, use commit1 (a parte excluída do intervalo) como <commit>. Pode ser passado várias vezes; nesse caso, um commit será incluído se for qualquer um dos commits fornecidos ou se for um ancestral ou descendente de um deles.

Segue explicações com mais detalhes.

Suponha que você tenha especificado foo como <caminhos>. Chamaremos os commits que modificam o foo de !TREESAME, e o restante de TREESAME. (Num diff filtrado para foo, eles parecem diferentes e iguais, respectivamente.)

A seguir, sempre nos referiremos ao mesmo exemplo do histórico para ilustrar as diferenças entre as configurações da simplificação. Presumimos que você esteja filtrando um arquivo foo neste gráfico de commits:

	  .-A---M---N---O---P---Q
	 /     /   /   /   /   /
	I     B   C   D   E   Y
	 \   /   /   /   /   /
	  `-------------'   X

A linha horizontal do histórico A---Q é considerada o primeiro ramo principal de cada mesclagem. Os commits são:

O I é o commit inicial onde foo existe com o conteúdo “asdf” e existe um arquivo quux com o conteúdo` quux ''. Os commits iniciais são comparados com uma árvore vazia, então o `I é !TREESAME.
Em A, foo contém apenas “foo”.
B contém a mesma alteração que A. A sua fusão M é trivial e, portanto, TREESAME para todos os principais.
O C não muda foo, mas a sua mesclagem N o altera para “foobar”, portanto não é TREESAME para nenhum dos pais.
D define foo para “baz”. Mescla O combinado com textos vindos de ` N` e D a “foobarbaz”; ou seja, não é "TREESAME" para nenhuma das origens.
O E altera quux para “xyzzy” e a sua mesclagem P combina as sequências dos caracteres para “quux xyzzy”. O P é TREESAME para O, porém não para E.
O X é um commit raiz independente que adicionou um novo arquivo side, e Y o alterou. O Y é TREESAME para X. Mescla Q adicionou side para P, e Q e TREESAME para P, mas não para Y.

O rev list retrocede no histórico, incluindo ou excluindo os commits com base no uso do --full-history e/ou na reescrita dos pais (através da opção --parents ou --children). As seguintes configurações estão disponíveis.

Modo predefinido

Os commits são incluídos se não forem TREESAME para qualquer ramo principal (embora isso possa ser alterado, consulte a opção --sparse abaixo). Se o commit foi uma mesclagem e foi TREESAME para uma origem, siga apenas esta origem. (Mesmo que haja vários pais TREESAME, siga apenas um deles.) Caso contrário, siga todos os ramos principais.

Isso resulta em:

	  .-A---N---O
	 /     /   /
	I---------D

Observe como a regra de seguir apenas o principal TREESAME, se houver um disponível, removeu o B completamente da consideração. O C foi considerado via N, mas é TREESAME. Os commits principais são comparados a uma árvore vazia, portanto, I é !TREESAME.

As relações entre pai/filho são visíveis apenas com --parents, porém isso não afeta os commits selecionados no modo predefinido, portanto, mostramos as linhas dos pais.

--full-history sem reescrita anterior

Este modo difere do predefinido num ponto: sempre segue todos os pais de uma mesclagem, mesmo que seja TREESAME para um deles. Mesmo que mais de um lado da mesclagem tenha commits incluídos, isso não significa que a mesclagem em si esteja! No exemplo, nós temos

	I  A  B  N  D  O  P  Q

O M foi excluído porque é TREESAME para ambos os ramos principais. E, C e B foram todos percorridos, mas apenas B era !TREESAME, então os outros não aparecem.

Observe que, sem reescrever os pais, não é realmente possível falar sobre os relacionamentos pai/filho entre os commits, portanto, mostramos-lhes desconectados.

--full-history com reescrita anterior

Os commits comuns são incluídos apenas se forem !TREESAME (embora é possível alterar isso, consulte --sparse abaixo).

As mesclagens são sempre incluídas. No entanto, a sua lista principal é reescrita: Ao longo de cada ramo principal, elimine os commits que não estão incluídos. Isso resulta em

	  .-A---M---N---O---P---Q
	 /     /   /   /   /
	I     B   /   D   /
	 \   /   /   /   /
	  `-------------'

Compare com a opção --full-history sem reescrever acima. Observe que E foi eliminado porque é TREESAME, mas a lista dos principais de P foi reescrito para conter o principal de E, I. O mesmo aconteceu com C e N, e X, Y e Q.

Além das configurações acima, é possível alterar se o TREESAME afeta a inclusão:

--dense

Os commits encaminhados serão incluídos caso não sejam um TREESAME para nenhum dos parentes.

--sparse

Todos os commits que forem passados serão incluidos.

Observe que sem o --full-history, isso ainda simplifica as mesclagens: caso um dos pais seja TREESAME, seguiremos apenas este, para que os outros lados da mesclagem nunca sejam percorridos.

--simplify-merges

Primeiro, construa um grafo do histórico da mesma maneira que --full-history com a reescrita dos parentes (veja acima).

Simplifique cada commit C para a sua reposição C' no histórico final, de acordo com as seguintes regras:

Defina C' para C.
Substitua cada principal P de C' pela sua simplificação P'. No processo, elimine os principais que são ancestrais de outros principais ou que são raiz, transfira TREESAME para uma árvore vazia e remova as duplicatas, mas tome cuidado para nunca eliminar todos os principais onde somos TREESAME.
Se, após essa reescrita dos pais, C' for um commit raiz ou de mesclagem (tem zero ou >1 principais), um commit de limite ou !TREESAME, ele permanecerá. Caso contrário, ele é substituído por seu único principal.

O efeito disso é melhor mostrado por meio da comparação com o --full-history com reescrita principal. O exemplo se torna:

	  .-A---M---N---O
	 /     /       /
	I     B       D
	 \   /       /
	  `---------'

Observe que as maiores diferenças entre N, P, e Q sobre --full-history:

A lista do ramo principal N teve o I removido, porque ele é um ancestral do outro ramo principal M. Ainda assim, o N permaneceu porque é !TREESAME.
A lista principal de P também teve o I removido. O P foi então removido completamente, porque tinha um ramo principal e é TREESAME.
A lista de pais de Q tinha` Y` simplificado para X. O X foi então removido, porque era uma raiz TREESAME. O Q foi removido completamente, porque tinha um pai e é TREESAME.

Há um outra modo de simplificação disponível:

--ancestry-path[=<commit>]

Limite os commits exibidos àqueles que sejam ancestrais do <commit>, ou que sejam descendentes do <commit>, ou são o <commit> em si.

Como um exemplo de caso, considere o seguinte histórico do commit:

	    D---E-------F
	   /     \       \
	  B---C---G---H---I---J
	 /                     \
	A-------K---------------L--M

Um D..M regular calcula o conjunto dos commits que são ancestrais do M, mas exclui os que são ancestrais do D. Isso é útil para ver o que aconteceu com a história que levou a M desde o D, no sentido que “o que M possui e que não existia em D”. O resultado neste exemplo seria todos os commits, exceto A e B (e D, obviamente).

No entanto, quando quisermos descobrir quais commits em M estão contaminados com o bug introduzido por D e precisam ser corrigidos, talvez seja do nosso interesse visualizar apenas o subconjunto D..M que são realmente descendentes de D, ou seja, excluindo C e K. Isso é exatamente o que a opção --ancestry-path faz. Aplicado ao intervalo D..M, o resultado é:

		E-------F
		 \       \
		  G---H---I---J
			       \
				L--M

Também podemos usar --ancestry-path=D em vez de --ancestry-path que significa a mesma coisa quando é aplicado ao intervalo D..M, porém, é apenas mais explícito.

Se, em vez disso, estivermos interessados num determinado tópico dentro deste intervalo e em todos os commits afetados por este tópico, talvez seja do nosso interesse visualizar apenas o subconjunto D...M que contém esse tópico em seu caminho de ancestralidade. Portanto, usar --ancestry-path=H D...M, por exemplo, resultaria em:

		E
		 \
		  G---H---I---J
			       \
				L--M

Onde --ancestry-path=K D..M resultará em

		K---------------L--M

Antes de discutir outra opção, --show-pulls, precisamos criar um novo histórico de exemplo.

Um problema comum que os usuários enfrentam ao examinar o histórico simplificado é que um commit que eles conhecem alterou um arquivo e que de alguma maneira não aparece no histórico simplificado do arquivo. Vamos demonstrar um novo exemplo e exibir como as opções como --full-history e --simplify-merges funcionam neste caso:

	  .-A---M-----C--N---O---P
	 /     / \  \  \/   /   /
	I     B   \  R-'`-Z'   /
	 \   /     \/         /
	  \ /      /\        /
	   `---X--'  `---Y--'

Para este exemplo, suponha que I tenha criado o arquivo file.txt que foi alterado por A, B e X de maneiras diferentes. Os commits do único ramo principal C, Z e Y não alteram o arquivo file.txt. O commit de mesclagem M foi criado ao solucionar o conflito de mesclagem para incluir ambas as alterações de A e B e, portanto, não é TREESAME para nenhum deles. A mesclagem do commit R, no entanto, foi criado ignorando o conteúdo do arquivo file.txt em M e pegando apenas o conteúdo do arquivo file.txt em X. Portanto, R é TREESAME para X, mas não para M. Por fim, a resolução da mesclagem natural para criar N é pegar o conteúdo do arquivo file.txt em R, de modo que N é TREESAME para R, mas não para C. A mesclagem dos commits O e P são TREESAME para os seus primeiros ramos principais, mas não para os seus os ramos principais secundários, Z e Y respectivamente.

Ao utilizar os modos predefinidos, ambos os N e R tem um pai TREESAME, então aquelas bordas são percorridas e outras são ignoradas. E o grafo resultante no histórico é:

	I---X

Ao utilizar a opção --full-history, O Git percorre cada canto. Descobre se os commits A, B e o mesclado M, porém também revela se o commit mesclado O e P. Com a reescrita do pai, o resultado do grafo é:

	  .-A---M--------N---O---P
	 /     / \  \  \/   /   /
	I     B   \  R-'`--'   /
	 \   /     \/         /
	  \ /      /\        /
	   `---X--'  `------'

Aqui, a mesclagem do commit O e P contribuem com um ruído extra, pois na verdade não contribuíram com uma alteração no file.txt. Eles mesclaram apenas um topic com base numa versão mais antiga do file.txt. Este é um problema comum em repositórios que utilizam um fluxo de trabalho onde que muitos colaboradores trabalham em paralelo e mesclam as suas ramificações dos tópicos em um único tronco: muitas mesclagens não relacionadas aparecem nos resultados da opção --full-history.

Ao utilizar a opção --simplify-merges, os commits O e P desaparecem dos resultados. Pois as reescritas do segundo pai de O e P são acessíveis a partir dos seus primeiros pais. Estes cantos são removidos e então os commits se parecem com commits com pai singular só que são TREESAME em relação aos seus pais. Isso também acontece ao commit N, resultando no histórico a seguir:

	  .-A---M--.
	 /     /    \
	I     B      R
	 \   /      /
	  \ /      /
	   `---X--'

Nesta visão, vemos todas as alterações importantes da única origem vindas de A, B e X. Também vemos a mesclagem cuidadosamente resolvida de M e a mesclagem nem tão bem resolvida do R. Geralmente são informações suficientes para determinar por que os commit A e B "desapareceram" do histórico na visualização predefinida. No entanto, existem alguns problemas com esta abordagem.

O primeiro problema é o desempenho. Diferente das opções anteriores, a opção --simplify-merges precisa percorrer todo o histórico do commit antes de retornar um único resultado. Isso pode fazer com que a opção seja difícil de usar em repositórios muito grandes.

O segundo problema é a auditoria. Quando muitos colaboradores estão trabalhando no mesmo repositório, é importante saber qual mesclagem do commit introduziu uma importante alteração no ramo. A mesclagem problemática R acima não parece ser o commit mesclado que foi utilizado na mesclagem de um ramo importante. Em vez disso, a mesclagem N foi utilizada para mesclar R e X em um importante ramo. Este commit por ter informação sobre o por que do X chegou a substituir as alterações do A e B em suas mensagens do commit.

--show-pulls

Além dos commits exibidos no histórico predefinido, exiba cada mesclagem do commit que não seja TREESAME para o primeiro parente, porém que seja TREESAME para um parente posterior.

Quando a mesclagem de um commit é incluso através da opção --show-pulls, a mesclagem é tratada como tivesse "capturado" as alterações de um outro ramo. Ao usar a opção --show-pulls nest exemplo (e em nenhuma outra opção) o grafo resultante será:

	I---X---R---N

Aqui, a mesclagem do commit R e N são incluídos porque obtiveram os commits X e R para o ramo base, respectivamente. Essas mesclagens são a razão pela qual os commits A e B não aparecem no histórico predefinido.

Quando a opção --show-pulls for usado em conjunto com --simplify-merges, o grafo incluí todas as informações necessárias:

	  .-A---M--.   N
	 /     /    \ /
	I     B      R
	 \   /      /
	  \ /      /
	   `---X--'

Repare que desde que M seja acessível de R, o canto de N para M foi simplificado. No entanto, o N ainda aparece no histórico como um commit importante porque ele "obteve" as alterações vindas de R para o ramo principal.

A opção --simplify-by-decoration permite que você veja apenas o quadro geral da topologia do histórico, omitindo os commits que não são mencionados pelas etiquetas. Os commits são marcados como !TREESAME (em outras palavras, mantidos após as regras de simplificação do histórico descritas acima) se (1) forem mencionados pelas etiquetas ou (2) alterarem o conteúdo dos caminhos fornecidos na linha de comando. Todos os outros commits são marcados como TREESAME (que estão sujeitos a serem simplificados).

Ordenando os Commits

É predefinido que os commits sejam exibidos em uma ordem cronológica reversa.

--date-order

Não exiba nenhuma origem antes de todos os herdeiros, porém exiba os commits com uma ordem de data e hora.

--author-date-order

Não exiba nenhuma origem antes de todos os herdeiros, porém exiba os commits com uma ordem de data e hora do autor.

--topo-order

Não exiba nenhuma origem antes de todos os herdeiros e evite exibir os commits com múltiplas linhas misturadas no histórico.

Por exemplo, em um histórico de commit como este:

    ---1----2----4----7
	\	       \
	 3----5----6----8---

onde os números indicam a ordem dos registros de data e hora do commit, o comando git rev-list e seus amigos --date-order exibem os commits na ordem de registro de data e hora: 8 7 6 5 4 3 2 1.

Com --topo-order, eles demonstrariam 8 6 5 3 7 4 2 1 (ou 8 7 4 2 6 5 3 1); alguns commits mais antigos são exibidos antes dos mais recentes, a fim de se evitar exibir os commits das duas trilhas de desenvolvimento paralelas misturadas juntas.

--reverse

Envie os commits escolhidos para serem exibidos (consulte a seção Limite do Commit acima) na ordem inversa. Não pode ser combinado com --walk-reflogs.

Passagem de Objeto

Essas opções são direcionadas principalmente para o empacotamento dos repositórios Git.

--no-walk[=(sorted|unsorted)]: Mostra apenas os commits mencionados, mas não percorre os seus ancestrais. Isso não terá efeito se um intervalo for especificado. Se a opção unsorted for usado, os commits serão mostrados na ordem em que foram fornecidos na linha de comando. Caso contrário (se sorted ou nenhuma opção for fornecido), os commits serão mostrados em ordem cronológica reversa de acordo com a hora do commit. Não pode ser combinado com a opção --graph.
--do-walk: Substitui um --no-walk anterior.

Formatação do Commit

--pretty[=<formato>]
--format=<formato>: Imprima o conteúdo dos registros do commit num determinado formato, onde <format> pode ser oneline, short, medium, full, fuller, reference, email, raw, format:<string> e tformat:<string>. Quando <format> não for nenhuma das opções acima e tem %placeholder, ele age como se a opção --pretty=tformat:<formato> tivesse sido usado.

Consulte a seção "FORMATOS BONITOS" para obter alguns detalhes adicionais sobre cada formato. Quando a parte =<formato> é omitida, a predefinição é 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 mostrar o nome hexadecimal com 40 bytes completo do objeto commit, mostre um prefixo que nomeie o objeto de maneira exclusiva. A opção --abbrev=<n> (que também modifica a saída do diff, se for exibida) pode ser usada para especificar o comprimento mínimo do prefixo.

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, de forma explícita ou implícita pelas outras opções 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 dos caracteres usado para a mensagem de registro log em seu cabeçalho de codificação; esta opção pode ser usada para informar ao comando para recodificar a mensagem de registro log do commit na codificação preferida pelo usuário. Para comandos que não sejam para redirecionamento, o padrão é UTF-8. Observe que, se um objeto alegar ser codificado em X e estivermos produzindo em X, produziremos o objeto literalmente; isso significa que as sequências inválidas no commit original podem ser copiadas para o objeto criado. Da mesma maneira, se o iconv(3) não conseguir converter o commit, faremos o envio literal do objeto original.
--expand-tabs=<n>
--expand-tabs
--no-expand-tabs: Execute uma expansão de tabulação (substitua cada tabulação por espaços suficientes para preencher a próxima coluna de exibição que seja um múltiplo de <n>) na mensagem de registro antes de mostrá-la na saída. A opção --expand-tabs é uma abreviação de --expand-tabs=8 e --no-expand-tabs é uma abreviação de --expand-tabs=0, que desativa a expansão das guias.

È predefinido que as guias sejam expandidas em formatos bonitos que recuam a mensagem de registro em 4 espaços (ou seja, a predefinição medium, full e fuller).
--notes[=<ref>]: Mostre as notas (consulte git-notes[1]) que anotam o commit, ao mostrar a mensagem de registro do commit. Esta é a predefinição para os comandos git log, git show e git whatchanged quando não há nenhuma opção --pretty, --format ou --oneline usada 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>, use a referência para localizar as notas a serem exibidas. Uma ref pode especificar o nome completo da ref quando começa com refs/notes/; quando começa com notes/, refs/ e, caso contrário, refs/notes/ é prefixado para formar o 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 mostrar as anotações. Isso anula a opção --notes acima, redefinindo a lista de refs das anotações a partir de onde as notas são exibidas. As opções são analisadas na ordem usada na linha de comando, portanto, por exemplo, --notes --notes=foo --no-notes --notes=bar mostrará apenas as notas de refs/notes/bar.
--show-notes-by-default: Mostra as notas predefinidas, a menos que sejam fornecidas opções para a exibição de notas específicas.
--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.

--relative-date

É um sinônimo para --date=relative.

--date=<formato>

Somente entra em vigor para as datas demonstradas no formato legível para as pessoas como utilizada na opção --pretty. A variável de configuração log.date define um valor predefinido para a opção --date do comando do registro log. É predefinido que os horários sejam exibidas no fuso horário original (do autor do commit ou do autor). Caso -local seja anexado ao formato (por exemplo,iso-local), o fuso horário local do usuário será utilizado.

A opção --date=relative exibe as datas relativas à hora atual, por exemplo, “2 horas atrás”. A opção -local não tem efeito para --date=relative.

--date=local é um apelido para --date=default-local.

--date=iso (ou --date=iso8601) mostra os registros de data e hora num formato semelhante ao ISO 8601. As diferenças em relação ao formato estrito da ISO 8601 são:

um espaço em vez do T para delimitar data/hora
um espaço entre a hora e o fuso horário
sem dois pontos entre horas e minutos do fuso horário

a opção --date=iso-strict (ou --date=iso8601-strict) exibe o registro de data e hora com formato ISO 8601 restrito.

a opção --date=rfc (ou --date=rfc2822) exibe o registro de data e hora no formato RFC 2822, geralmente encontrado nas mensagens de e-mail.

--date=short exibe apenas a data em formato AAAA-MM-DD porém não a hora.

A opção --date=raw mostra a data como segundos desde a partir da época (1970-01-01 00:00:00 UTC), seguida por um espaço e, em seguida, o fuso horário como um offset do UTC (apresentado com um + ou - com quatro dígitos; os dois primeiros são horas e os dois segundos são minutos). Ou seja, como se o registro de data e hora fosse formatado com strftime("%s %z")). Observe que a opção -local não afeta o valor de "seconds-since-epoch" (que é sempre medido em UTC), mas altera o valor do fuso horário que o acompanha.

A opção --date=human mostra o fuso horário se o fuso horário não corresponder ao fuso horário atual e não mostra a data inteira se houver correspondência (ou seja, não mostra o ano para datas que são "deste ano", mas também não mostra a data inteira se ela estiver nos últimos dias e pudermos apenas dizer que dia da semana foi). A hora e o minuto também são omitidos para datas mais antigas.

A opção --date=unix mostra a data como um registro de data e hora da época Unix (segundos desde 1970). Assim como no caso do --raw, ele está sempre em UTC e, portanto, a opção -local não tem efeito.

A opção --date=format:... alimenta o formato ... em seu sistema strftime, com exceção de %s, %z e %Z, que são tratados internamente. Use --date=format:%c para mostrar a data no formato preferido da localidade do seu sistema. Consulte o manual do strftime para obter uma lista completa dos marcadores de formato. Ao usar -local, a sintaxe correta é --date=format-local:....

A opção --date=default é o formato predefinido e tem como base na saída do ctime(3). Ele mostra uma única linha com três letras do dia da semana, três letras do mês, dia do mês, hora-minuto-segundos no formato "HH:MM:SS", seguido pelo ano de quatro dígitos, além de informações de fuso horário, a menos que o fuso horário local seja usado, por exemplo, Thu Jan 1 00:00:00 1970 +0000.

--parents

Mostre também as origens do commit (na opção "commit parent…"). Também permite a reescrita do ramo principal, consulte Simplificação do histórico acima.

--children

Mostre também os commit relacionados (na opção "commit child…"). Também permite a reescrita do ramo principal, consulte Simplificação do histórico acima.

--left-right

Marca de que lado de uma diferença simétrica um commit pode ser acessado. Os commits do lado esquerdo são marcados com < e os do lado direito com >. Se combinados com --boundary, estes commits são marcados com -.

Por exemplo, caso tenha essa topologia:

	     y---b---b  branch B
	    / \ /
	   /   .
	  /   / \
	 o---x---a---a  branch A

você obterá uma saída como essa:

	$ git rev-list --left-right --boundary --pretty=oneline A...B

	>bbbbbbb... 3º no b
	>bbbbbbb... 2º no b
	<aaaaaaa... 3º no a
	<aaaaaaa... 2º no a
	-yyyyyyy... 1º no b
	-xxxxxxx... 1º no a

--graph

Desenhe uma representação gráfica em texto do histórico do commit no lado esquerdo da saída. Isso pode fazer com que linhas extras sejam mostradas entre os commits, para que o histórico do gráfico seja desenhado corretamente. Não pode ser combinado com a opção --no-walk.

Permite a reescrita dos pais, consulte Simplificação do Histórico acima.

É predefinido que seja implícito o uso da opção --topo-order, porém a opção --date-order também possa ser utilizada.

--show-linear-break[=<barreira>]

Quando a opção --graph não é utilizado, todas as ramificações do histórico são achatadas, o que dificulta a visualização onde dois commits consecutivos não pertençam em um ramo linear. Neste caso, esta opção coloca uma barreira entre eles. Caso <barreira> seja utilizado, é a string que será exibida em vez do que estiver predefinido.

FORMATOS BONITOS

Se o commit for uma mesclagem e se o formato "pretty" não for oneline, email ou raw, uma linha adicional será inserida antes da linha Author:. Essa linha começa com "Merge: " e os hashes dos commits ancestrais são impressos e separados por espaços. Observe que os commits listados podem não ser necessariamente a lista dos commits principais diretos se você tiver limitado a sua visão do histórico: se estiver interessado apenas nas alterações relacionadas a um determinado diretório ou arquivo por exemplo.

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 é usado para fazer referência a outro commit numa mensagem de commit e é o mesmo que --pretty='format:%C(auto)%h (%s, %ad)'. É predefinido que a data seja formatada com a opção --date=short, a menos que uma outra opção --date seja explicitamente especificada. Assim como qualquer format: com marcadores de formato, o que é gerado por ele não é afetado 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 raw mostra o commit inteiro exatamente como armazenado no objeto de commit. Notavelmente, os hashes são exibidos na íntegra, independentemente do uso da opção --abbrev ou --no-abbrev, e as informações de parents mostram os verdadeiros commits principais, sem levar em conta os enxertos ou a simplificação do histórico. Observe que este formato afeta a forma como os commits são exibidos, mas não a forma como o diff é exibido, por exemplo, com o comando git log --raw. Para obter os nomes completos dos objetos num formato diff bruto, use --no-abbrev.
format:<formato-do-texto>

O formato format:<formato-do-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
  
  %x seguido de dois dígitos hexadecimais é substituído por um byte com o valor dos dígitos hexadecimais (chamaremos isso de "código de formatação literal" no restante deste documento).
- 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(…)
  
  Conforme foi descrito em Valores na seção "ARQUIVO DE CONFIGURAÇÃO" do comando git-config[1]. É predefinido que as cores são mostradas somente quando ativadas para a saída de registro (por color.diff, color.ui ou --color, respeitando as configurações auto do primeiro se estivermos indo para um terminal). O %C(auto,...) é aceito como sinônimo histórico do padrão (por exemplo, %C(auto,red)). Ao especificar %C(always,...) exibirá as cores mesmo quando a cor não estiver ativada (considere utilizar apenas a opção --color=always para ativar a cor para toda a saída, incluindo este formato e qualquer outra coisa que o git possa colorir). A opção auto sozinha (ou seja, %C(auto)) ativará a coloração automática nos próximos marcadores até que a cor seja trocada novamente.
  
  %m
  
  marca esquerda (<), direita (>) ou limite (-)
  
  %w([<w>[,<i1>[,<i2>]]])
  
  alterna a quebra da linha, como na opção -w do git-shortlog[1].
  
  %<( <N> [,trunc|ltrunc|mtrunc])
  
  Faz com que o próximo marcador ocupe pelo menos N larguras de coluna, preenchendo espaços à direita, se necessário. Opcionalmente, trunque (com reticências …) à esquerda (ltrunc) ..ft, no meio (mtrunc) mi..le ou no final (trunc) rig.., se a saída for maior que N colunas. Observação 1: esse truncamento só funciona corretamente com N >= 2. Observação 2: os espaços ao redor dos valores N e M (veja abaixo) são opcionais. Observação 3: Os emojis e outros caracteres longos ocuparão duas colunas de exibição, o que pode ultrapassar os limites da coluna. Observação 4: as marcas de combinação de caracteres decompostos podem estar mal posicionadas nos limites do preenchimento.
  
  %<|( <M> )
  
  Faz com que o próximo marcador ocupe pelo menos até a Mésima coluna de exibição, preenchendo espaços à direita, caso seja necessário. Use valores M negativos para posições de coluna medidas a partir da borda direita da janela do terminal.
  
  %>( <N> ), %>|( <M> )
  
  semelhante a %<( <N> ), %<|( <M> ) respectivamente, mas preenchendo os espaços à esquerda
  
  %>>( <N> ), %>>|( <M> )
  
  semelhante a %>( <N> ), %>|( <M> ) 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> ), %><|( <M> )
  
  semelhante a %<( <N> ), %<|(< M >) respectivamente, mas preenchendo ambos os lados (quando o texto for centralizado por exemplo)
- 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
  
  o nome do autor (respeitando .mailmap, consulte git-shortlog[1] ou git-blame[1])
  
  %ae
  
  e-mail do autor
  
  %aE
  
  o 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 do autor local (rconsulte %al) espeitando o .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)
  
  %ah
  
  data da autoria, compreensível para pessoas (como a opção --date=human do git-rev-list[1])
  
  %cn
  
  nome de quem fez o commit
  
  %cN
  
  o 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
  
  o 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
  
  a parte local de quem fez o commit (consulte %cl) respeitando o .mailmap, consulte see 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)
  
  %ch
  
  a data de quem fez o commit, compreensível para pessoas (como a opção --date=human do git-rev-list[1])
  
  %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 " (", ")".
  
  %(decorate[:<opções>])
  
  nomes de ref com decorações personalizadas. A string decorate pode ser seguida por dois pontos e zero ou mais opções separadas por vírgulas. Os valores das opções podem conter códigos de formatação literais. Eles devem ser usados para vírgulas (%x2C) e parênteses de fechamento (%x29), devido à sua função na sintaxe da opção.
  
  O prefix=<valor>: Exibido antes da lista de nomes ref. A predefinição é " (".
  
  O prefix=<valor>: Exibido antes da lista de nomes ref. A predefinição é ")".
  
  O separator=<valor>: Mostrado entre os nomes refs. A predefinição é ", ".
  
  pointer=<valor>: Mostrado entre HEAD e o ramo para o qual aponta, se houver. A predefinição é " -> ".
  
  tag=<valor>: Mostrado antes dos nomes das tags. A predefinição é "tag: ".
Por exemplo, para produzir decorações sem anotações nas tags, de envelopamento ou de espaços como separadores:

+ %(decorate:prefix=,suffix=,tag=,separator= )
%(describe[:<opções>])
Um nome legível para humanos, como git-describe[1]; string vazia para commits sem descrição. A string describe pode ser seguida por dois-pontos, zero ou mais opções separadas por vírgulas. As descrições podem ser inconsistentes quando as etiquetas são adicionadas ou são removidas ao mesmo tempo.
tags[=<bool-value>]: Em vez de considerar apenas as tags anotadas, considere também as lightweight tags.

abbrev=<número>: Em vez de usar o número padrão com dígitos hexadecimais (que variam de acordo com a quantidade dos objetos no repositório com um padrão de 7) do nome abreviado do objeto, utilize <número> dígitos ou quantos dígitos forem necessários para formar um nome do objeto que seja único.

match=<pattern>: Considere apenas as etiquetas que coincidam com o padrão glob(7) informado, excluindo o prefixo "refs/tags/".

exclude=<pattern>: Desconsidere as etiquetas que coincidam com o padrão glob(7) informado, excluindo o prefixo "refs/tags/".
%S

os nomes "ref" dado na linha de comando pela qual o commit foi alcançado (como git log --source), só funciona com o comando 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?

Mostre "G" para uma assinatura boa (válida), "B" para uma assinatura ruim, "U" para uma assinatura boa com validade desconhecida, "X" para uma assinatura boa que expirou, "Y" para uma assinatura boa feita por uma chave expirada, "R" para uma assinatura boa feita por uma chave revogada, "E" se a assinatura não puder ser verificada (falta de chave por exemplo) e "N" para nenhuma 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, como por exemplo, refs/stash@{1} or 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

o encurtamento do seletor do reflog; o mesmo que %gD, porém a parte do refname é reduzida visando a legibilidade humana (assim, o refs/heads/master se torna apenas master).

%gn

nome da identidade "reflog"

%gN

nome da identidade do reflog (respeitando .mailmap, consulte git-shortlog[1] ou git-blame[1])

%ge

e-mail da identidade reflog

%gE

e-mail da identidade do reflog (respeitando .mailmap, consulte git-shortlog[1] ou git-blame[1])

%gs

assunto reflog

%(trailers[:<opções>])
exibe os trechos do corpo como interpretado através do git-interpret-trailers[1]. Os trechos do texto da resposta podem ser seguidas por dois pontos, zero ou mais opções separadas por vírgula: Caso qualquer opção seja usada várias vezes, a última ocorrência ganha.
A key=<chave>: mostra apenas os caracteres de resposta com a <chave> especificada. A correspondência é feita sem distinção entre maiúsculas e minúsculas, os dois-pontos finais são opcionais. Se a opção for usada várias vezes, serão mostradas as linhas dos caracteres de resposta que correspondem a qualquer uma das chaves. Esta opção ativa automaticamente a opção only para que as linhas que não tenham caracteres de resposta no bloco oculto com caracteres de resposta. Se isso não for desejado, desative com only=false. Por exemplo, %(trailers:key=Revisado-por) mostra as linhas do trailer com a chave Revisado-por.

only[=<bool>]: selecione se as linhas não relacionadas à resposta a partir do bloco de resposta, devem ser incluídas ou não.

separator=<sep>: specify the separator inserted between trailer lines. Defaults to a line feed character. The string <sep> may contain the literal formatting codes described above. To use comma as separator one must use %x2C as it would otherwise be parsed as next option. E.g., %(trailers:key=Ticket,separator=%x2C ) shows all trailer lines whose key is "Ticket" separated by a comma and a space.

unfold[=<bool>]: faça com que se comporte como se a opção --unfold do caracteres de resposta tenha sido passado. Por exemplo, %(trailers:only,unfold=true) desdobra e mostra todas as linhas de resposta.

keyonly[=<bool>]: mostra apenas a parte principal da resposta.

valueonly[=<bool>]: mostra apenas o valor da parte da resposta.

key_value_separator=<sep>: specify the separator inserted between the key and value of each trailer. Defaults to ": ". Otherwise it shares the same semantics as separator=<sep> above.

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.

As opções booleanas aceitam um valor opcional [=<bool>]. Todos os valores true, false, on, off etc. são aceitos. Consulte a subseção "booleana" em "EXEMPLOS" em git-config[1]. Caso uma opção booleana seja fornecida sem valor, ela será ativada.

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 o format:, exceto pelo fato de que ele fornece a semântica de "terminador" em vez da semântica de "separador". Em outras palavras, cada commit tem o caractere de terminação da mensagem (geralmente uma nova linha) anexado, em vez de um separador colocado entre as entradas. Isso significa que a entrada final de um formato único da linha será encerrada corretamente com uma nova linha, exatamente como o formato "oneline" faz. 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 % é interpretada como se tivesse tformat: na frente. Por exemplo, estes dois são equivalentes:
```
$ git log -2 --pretty=tformat:%h 4da45bef
$ git log -2 --pretty=%h 4da45bef
```

FORMATAÇÃO DIFF

Por predefinição, o comando git log não gera qualquer diff. As opções abaixo podem ser usadas para exibir as alterações feitas por cada commit.

Note que a menos que uma das variantes --diff-merges (incluindo as opções curtas`-m`, -c e --cc e --dd) seja explicitamente informada, a mesclagem dos commits não mostrarão um diff, mesmo se um diff formato como --patch seja escolhido, nem corresponderá às opções de pesquisa como -S. A exceção é quando a opção --first-parent está em uso, neste caso`first-parent` é o formato predefinido para mesclar os commits.

-p

-u

--patch

Gerar patch (consulte Gerando a correção em um formato texto com a opção -p).

-s

--no-patch

Suprime toda a saída do mecanismo, diff. É útil para comandos como git show que, por padrão, mostram o patch para abafar a sua saída, ou para cancelar o efeito de opções como --patch, --stat anteriormente na linha de comando num alias.

-m

Mostra os diffs dos commits mesclados no formato padrão. Isso é semelhante a --diff-merges=on, exceto com a opção -m que não produzirá nada a menos que -p também seja usado.

-c

Gera um diff combinado nos commits mesclados. É um atalho para --diff-merges=combined -p.

--cc

Gera um diff denso e combinado nos commits mesclados. É um Atalho para --diff-merges=dense-combined -p.

--dd

Produzir um diff com relação ao primeiro arquivo principal para commits regulares e mesclados. É um atalho para --diff-merges=first-parent -p.

--remerge-diff

Gera um remerge-diff para commits mesclados. É um atalho para --diff-merges=remerge -p.

--no-diff-merges

È um sinônimo para --diff-merges=off.

--diff-merges=<formato>

Define o formato diff que será usado para a mesclagem dos commits. A predefinição é `off` a menos que a opção --first-parent esteja em uso, nesse caso a predefinição será first-parent.

Os seguintes formatos são compatíveis:

off, none: Desativa a saída dos diffs para a mesclagem dos commits. Útil para substituir valores implícitos.
on, m: Gera diff dos diferentes arquivos mesclados para que sejam mostrados no formato padrão. O formato padrão pode ser alterado usando a variável de configuração log.diffMerges, cujo valor padrão é separate.
first-parent, 1: Mostra o diff completo com relação ao primeiro arquivo principal. Esse é o mesmo formato que a opção --patch produz nos commits não mesclados.
separate: Mostra a diferença completa com relação a cada uma das origens. Uma entrada de registro e diff separadas são geradas para cada um dos arquivos principais.
combined, c: Mostra as diferenças de cada uma das origens para a mesclagem resultante de forma simultânea em vez de mostrar a diferença pareada entre uma origem e o resultado, um de cada vez. Além disso, lista apenas os arquivos que foram alterados a partir de todas as origens.
dense-combined, cc: Comprime ainda mais o arquivo gerado pelo comando --diff-merges=combined ao omitir os blocos menos importantes cujo conteúdo relacionado possua apenas duas variantes e o resultado da mesclagem escolhe um deles sem alteração.
remerge, r: Mescla novamente os dois principais commits para criar um objeto temporário na árvore—potencialmente contendo arquivos com os marcadores de conflito e tal. Um diff é então mostrado entre essa árvore temporária e o commit real da mesclagem.

A saída é gerada quando esta opção usada está sujeita a alterações, assim como a sua interação com as outras opções (a menos que esteja explicitamente documentada).

--combined-all-paths

Esta opção faz com que os diffs combinados (usados para a mesclagem dos commits) listem o nome relacionados de todos os arquivos. Dessa forma, só tem efeito quando a opção --diff-merges=[dense-]combined são utilizados e provavelmente é útil apenas caso as alterações no nome do arquivo sejam detectados (ou seja, quando a renomeação ou a detecção da cópia forem solicitadas).

-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.

--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.

-t

Exibe os objetos árvore no diff que foi gerado.

--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 usada 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 tem como padrão a largura do terminal ou 80 colunas caso não esteja conectado num terminal, e pode ser substituído por <largura>. A largura da parte do nome do arquivo pode ser limitado ao fornecer outra largura <largura-do-nome> após uma vírgula ou definindo com diff.statNameWidth=<width>. A largura da parte do gráfico pode ser limitada pelo uso de --stat-graph-width=<largura> ou pela configuração de diff.statGraphWidth=<largura>. A utilização de --stat ou --stat-graph-width afeta todos os comandos que geram um gráfico estatístico, enquanto a definição diff.statNameWidth ou diff.statGraphWidth não afeta o git format-patch. Ao fornecer um terceiro parâmetro <count>, você pode limitar a saída às primeiras <count> linhas, seguidas de ... 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 num arquivo. Em outras palavras, reorganizar as linhas num 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 num 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 num 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 de arquivos alterados e acumulando as contagens dos diretórios filhos nos diretórios pais: --dirstat=files,10,cumulative.

--cumulative

É um sinônimo para --dirstat=cumulative

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

É um sinônimo para --dirstat=files,<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 "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 git-config[1]).

--name-only

Show only the name of each changed file in the post-image tree. The file names are often encoded in UTF-8. For more information see the discussion about encoding in the git-log[1] manual page.

--name-status

Show only the name(s) and status of each changed file. See the description of the --diff-filter option on what the status letters mean. Just like --name-only the file names are often encoded in UTF-8.

--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 num 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 numa 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 num 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 ~ numa 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.

--abbrev[=<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, exibe o prefixo mais curto que se refira de forma única ao objeto e que tenha até <n> hexdigits. No formato da produção da saída do diff-patch, a opção --full-index tem maior prioridade, ou seja, caso --full-index seja especificado o nome completo da bolha será exibido independente da opção --abbrev. A quantidade dos dígitos fora do preestabelecido pode ser especificado através da 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 precisa de algumas ações preliminares que podem detectar os subconjuntos das renomeações/cópias simples, seguidos por uma exaustiva porção de recursos que compara o resto de todos os destinos que ainda não foram reparados com todas as fontes relevantes. (Para as renomeações, apenas as fontes restantes que não foram pareadas são relevantes; nas cópias, todas as fontes originais são relevantes). Para N fontes e destinos, esta verificação exaustiva é O(N^2). Esta opção impede que a parte exaustiva da detecção de renomeamento/cópia seja executada caso a quantidade dos arquivos de origem/destino envolvidos exceda a quantidade definida. Caso contrário, retorna para o valor definido em diff.renameLimit. Observe que o valor 0 é tratado como ilimitado.

--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 minúsculas para serem excluídas. O comando --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, 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 usada (ou seja, adição/exclusão) num 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 numa <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.

--skip-to=<arquivo>

--rotate-to=<arquivo>

Descarte os arquivos da saída antes do <arquivo> (ou seja, pule para), ou mova-os para o final da saída (ou seja, redirecione para). Estas opções foram inventadas para uso do comando git difftool e podem não ser muito úteis para outra coisa.

-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 definir 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.

-I<expressão-regular>

--ignore-matching-lines=<expressão-regular>

Ignore as alterações cujas linhas coincidam com a <expressão-regular>. Esta opção pode ser usada mais de uma vez.

--inter-hunk-context=<linhas>

Exibe o contexto entre os blocos diff, até a quantidade de linhas usada, 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

Exibe toda a função como linhas de contexto para cada alteração. O nome da função é determinada da mesma maneira que o git diff lida com os pedaços do cabeçalhos do patch (consulte Definindo um cabeçalho personalizado do hunk em gitattributes[5]).

--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.

--default-prefix

Use the default source and destination prefixes ("a/" and "b/"). This overrides configuration variables such as diff.noprefix, diff.srcPrefix, diff.dstPrefix, and diff.mnemonicPrefix (see git-config(1)).

--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, GIT_DIFF_OPTS (consulte git[1]) e o atributo diff (consulte gitattributes[5]).

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
```
Os cabeçalhos "hunk" mencionam o nome da função à qual o "hunk" se aplica. Consulte "Definindo um cabeçalho personalizado do hunk" em gitattributes[5] para detalhes de como adaptar a isto e para linguagens específicas.

O formato diff combinado

Qualquer comando que gere um diff pode utilizar a opção -c ou`--cc` para produzir um diff combinado ao mostrar uma mesclagem. Este é o formato predefinido ao mostrar as mesclagens com git-diff[1] ou git-show[1]. Observe também que é possível usar a opção --diff-merges que é adequada para qualquer um destes comandos para impor a geração dos diffs num determinado formato.

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 duas <árvore>s e não são utilizados pela combinação do formato diff.
É 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). Assim como, 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 log --no-merges: Exibe todo o histórico do commit, mas ignore todas as mesclagens
git log v2.6.12.. include/scsi drivers/scsi: Exibe todos os commits desde a versão v2.6.12 que alterou qualquer arquivo nos subdiretórios include/scsi ou drivers/scsi
git log --since="2 weeks ago" -- gitk: Mostrar as alterações feitas nas últimas duas semanas no arquivo "gitk". O -- é necessário para evitar confusão com o ramo chamado gitk
git log --name-status release..test: Exibe os commits que estão no ramo "test", mas não ainda no ramo "release", junto com a lista dos caminhos que cada commit modifica.
git log --follow builtin/rev-list.c: Exibe os commits que mudaram o arquivo builtin/rev-list.c, incluindo os commits que ocorreram antes do arquivo receber o nome atual.
git log --branches --not --remotes=origin: Exibe todas os commits que estão em qualquer uma das ramificações locais, mas não em quaisquer outras ramificações remotas rastreadas para origin (o que você tem mas na "origin" não).
git log master --not --remotes=*/master: Exibe todos os commits que estão no "master" local, mas não em nenhuma outra ramificação "master" do repositório remoto.
git log -p -m --first-parent: Mostra o histórico, incluindo as diferenças das alterações, mas apenas da perspectiva do “ramo principal”, ignorando os commits provenientes de ramos mesclados e mostrando as diferenças completas das alterações introduzidas pelas mesclagens. Isso só faz sentido quando se segue uma política rígida para mesclar todos os tópicos das ramificações ao permanecer numa única ramificação de integração.
git log -L '/int main/',/^}/:main.c: Exibe como a função main() no arquivo main.c evoluiu ao longo do tempo.
git log -3: Limita a quantidade de commits a serem exibidos em 3.

DISCUSSÃO

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

O conteúdo dos objetos bolha (blob) são sequências de bytes não interpretadas. Não há uma tradução de codificação no nível do núcleo.
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 cerne, trata os nomes do caminho simplesmente como sequências de bytes não NUL; não há conversões de codificação do nome do caminho (exceto no Mac e no Windows). Portanto, o uso de nomes com caminho não ASCII funcionará, em geral, mesmo em plataformas e sistemas de arquivos que usam codificações ASCII estendidas legadas. No entanto, os repositórios criados nesses sistemas não funcionarão corretamente em sistemas baseados em UTF-8 (Linux, Mac, Windows por exemplo) e vice-versa. Além disso, muitas ferramentas com base no Git simplesmente assumem que os nomes de caminho são UTF-8 e não exibem outras 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 do commit sejam codificadas em UTF-8, tanto o núcleo quanto o Git porcelain foram projetados para não impor o UTF-8 nos projetos. Se todos os participantes de um determinado projeto acharem mais conveniente usar codificações herdadas, o Git não o proibirá. Entretanto, há alguns aspectos que devem ser levados em consideração.

O comando git commit e o git commit-tree emitem um aviso se a mensagem de registro do commit fornecida a ele não se parecer com uma string UTF-8 válida, a menos que você diga explicitamente que o seu projeto usa uma codificação antiga. A maneira de definir isso é ter i18n.commitEncoding no arquivo .git/config, assim:
```
[i18n]
	commitEncoding = ISO-8859-1
```
Os objetos criados do commit com a configuração acima, registram o valor i18n.commitEncoding em seu cabeçalho encoding. Isso serve para ajudar as outras pessoas que forem examiná-las mais tarde. A ausência desse cabeçalho implica que a mensagem de registro do commit está codificada em UTF-8.
Os comandos git log, git show, git blame e outros, analisam o cabeçalho encoding de um objeto commit e tentam recodificar a mensagem de registro em UTF-8, a menos que outro seja especificado. Você pode especificar a codificação de saída desejada com i18n.logOutputEncoding no arquivo .git/config, da seguinte maneira:
```
[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.

CONFIGURAÇÃO

Para configurações relacionadas com a geração de arquivos diferenciais "diff" consulte git-diff[1], para as variáveis principais consulte git-config[1].

format.pretty: É a predefinição para a opção --format. (Consulte formatos bonitos acima.) A predefinição é medium.
i18n.logOutputEncoding: A codificação que será usada na exibição dos registros log. (Consulte "Discussão" acima.) A predefinição é o valor em i18n.commitEncoding, quando for definido, caso contrário, é UTF-8.

Warning

Missing pt_BR/includes/cmd-config-section-rest.txt

See original version for this content.

Warning

Missing pt_BR/config/log.txt

See original version for this content.

Warning

Missing pt_BR/config/notes.txt

See original version for this content.

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

NOME

RESUMO

DESCRIÇÃO

OPÇÕES

Limitação do Commit

Simplificação do histórico

Ordenando os Commits

Passagem de Objeto

Formatação do Commit

FORMATOS BONITOS

FORMATAÇÃO DIFF

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

O formato diff combinado

EXEMPLOS

DISCUSSÃO

CONFIGURAÇÃO

GIT

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