Este é o comando git-log que pode ser executado no provedor de hospedagem gratuita OnWorks usando uma de nossas várias estações de trabalho online gratuitas, como Ubuntu Online, Fedora Online, emulador online do Windows ou emulador online do MAC OS
PROGRAMA:
NOME
git-log - Mostrar logs de commit
SINOPSE
git log [ ] [ ] [[-] ...]
DESCRIÇÃO
Mostra os logs de confirmação.
O comando pega opções aplicáveis ao comando git rev-list para controlar o que é mostrado
e como, e opções aplicáveis aos comandos git diff- * para controlar como cada mudança
commit introduções são mostrados.
OPÇÕES
--Segue
Continue listando o histórico de um arquivo além de renomear (funciona apenas para um único arquivo).
--no-decorate, --decorate [= short | full | no]
Imprima os nomes de ref de quaisquer commits que são mostrados. Se baixo é especificado, o ref
prefixos de nome refs / heads /, refs / tags / e refs / remotes / não será impresso. Se completa
for especificado, o nome completo da ref (incluindo o prefixo) será impresso. A opção padrão
is baixo.
--fonte
Imprima o nome ref fornecido na linha de comando pelo qual cada confirmação foi alcançada.
--use-mailmap
Use o arquivo de mapa de correio para mapear nomes de autor e committer e endereços de e-mail para canônicos
nomes reais e endereços de e-mail. Ver git-shortlog(1).
--diferença completa
Sem este sinalizador, git log -p ... mostra confirmações que tocam os caminhos especificados,
e diffs sobre os mesmos caminhos especificados. Com isso, a diferença completa é mostrada para
confirma que tocam os caminhos especificados; Isso significa que " ... "limites apenas
commits, e não limita diff para esses commits.
Observe que isso afeta todos os tipos de saída baseados em diff, por exemplo, aqueles produzidos por --stat,
etc.
--log-size
Incluir uma linha “tamanho do log ”Na saída de cada confirmação, onde é
o comprimento da mensagem desse commit em bytes. Destina-se a acelerar as ferramentas que lêem o log
mensagens da saída do log do git, permitindo que eles aloquem espaço com antecedência.
-EU , : , -EU : :
Rastreie a evolução da faixa de linha dada por " , "(ou o nome da função
regex ) dentro do . Você não pode fornecer nenhum limitador de pathspec. Isto é
atualmente limitado a uma caminhada a partir de uma única revisão, ou seja, você só pode dar
zero ou um argumento de revisão positivo. Você pode especificar esta opção mais de uma vez.
e pode assumir uma das seguintes formas:
· número
Se ou é um número, ele especifica um número de linha absoluto (contagem de linhas
de 1).
· / Regex /
Este formulário usará a primeira linha correspondente ao regex POSIX fornecido. Se é um
regex, ele pesquisará a partir do final do intervalo -L anterior, se houver, caso contrário
desde o início do arquivo. Se é “^ / regex /”, pesquisará desde o início de
Arquivo. Se é um regex, ele pesquisará começando na linha fornecida por .
· + Deslocamento ou -offset
Isso é válido apenas para e irá especificar um número de linhas antes ou depois
a linha dada por .
Se ": ”É fornecido no lugar de e , é uma expressão regular
que denota o intervalo da primeira linha funcname que corresponde , até o
próxima linha funcname. “: ”Pesquisa a partir do final do intervalo -L anterior, se
qualquer, caso contrário, desde o início do arquivo. “^: ”Pesquisa desde o início do arquivo.
Mostra apenas os commits no intervalo de revisão especificado. Quando não é
especificado, o padrã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 da origem. Para uma lista completa de maneiras de soletrar , Veja o
Especificando Gamas Seção de revisões do gitre(7).
[-] ...
Mostra apenas os commits que são suficientes para explicar como os arquivos que correspondem ao especificado
caminhos surgiram. Ver História simplificação abaixo para detalhes e outros
modos de simplificação.
Os caminhos podem precisar ser prefixados com '`-' 'para separá-los das opções ou do
intervalo de revisão, quando surge confusão.
COMPROMETA-SE Limitando
Além de especificar uma gama de commits que devem ser listados usando as notações especiais
explicado na descrição, a limitação de confirmação adicional pode ser aplicada.
Usar mais opções geralmente limita ainda mais a saída (por exemplo, --since = limites para
commits mais novos que , e usando-o com --grep = limites adicionais para commits
cuja mensagem de registro tem uma linha que corresponde ), salvo indicação em contrário.
Observe que eles são aplicados antes de confirmar as opções de ordem e formatação, como
--reverter.
- , -n , --max-count =
Limite o número de confirmações para saída.
--skip =
pular número confirma antes de começar a mostrar a saída de confirmação.
--since = , --após =
Mostrar commits mais recentes do que uma data específica.
--até = , --antes =
Mostrar commits anteriores a uma data específica.
--author = , --committer =
Limite a saída dos commits para aqueles com linhas de cabeçalho do autor / committer que correspondam ao
padrão especificado (expressão regular). Com mais de um --author = , confirma
cujo autor corresponde a qualquer um dos padrões dados são escolhidos (da mesma forma para vários
--committer = )
--grep-reflog =
Limita a saída dos commits para aqueles com entradas reflog que correspondam ao padrão especificado
(expressão regular). Com mais de um --grep-reflog, confirma cuja mensagem de reflog
corresponde a qualquer um dos padrões fornecidos. É um erro usar esta opção, a menos que
--walk-reflogs está em uso.
--grep =
Limita a saída de commits para aqueles com mensagem de log que corresponda ao padrão especificado
(expressão regular). Com mais de um --grep = , confirma cuja mensagem
corresponde a qualquer um dos padrões dados são escolhidos (mas veja --todos os jogos).
Quando --show-notes está em vigor, a mensagem das notas é correspondida como se fosse
parte da mensagem de log.
--todas as partidas
Limita a saída dos commits para aqueles que correspondem a todos os dados --grep, ao invés daqueles que
corresponder a pelo menos um.
--invert-grep
Limita a saída de commits para aqueles com mensagem de log que não correspondem ao padrão
especificado com --grep = .
-i, --regexp-ignore-case
Corresponde aos padrões de limitação da expressão regular sem levar em conta maiúsculas e minúsculas.
--basic-regexp
Considere os padrões de limitação como expressões regulares básicas; este é o padrão.
-E, --extended-regexp
Considere os padrões de limitação como expressões regulares estendidas em vez do
expressões regulares básicas padrão.
-F, --strings fixas
Considere os padrões de limitação como strings fixas (não interprete o padrão como um
expressão regular).
--perl-regexp
Considere os padrões de limitação como expressões regulares compatíveis com Perl. Requer
libpcre a ser compilado.
--remove-vazio
Pare quando um determinado caminho desaparecer da árvore.
--merge
Imprime apenas commits de mesclagem. Isso é exatamente o mesmo que --min-parents = 2.
--sem mesclas
Não imprima commits com mais de um pai. Isso é exatamente o mesmo que
--max-pais = 1.
--min-Parents = , --max-parentes = , --no-min-Parents, --no-max-Parents
Mostra apenas os commits que têm pelo menos (ou no máximo) esse número de commits pai. No
particular, --max-Parents = 1 é o mesmo que --no-merges, --min-Parents = 2 é o mesmo que
--merges. --max-Parents = 0 fornece todos os commits de root e --min-Parents = 3 todos os polvos
mescla.
--no-min-parents e --no-max-parents redefinem esses limites (para nenhum limite) novamente.
As formas equivalentes são --min-parents = 0 (qualquer commit tem 0 ou mais pais) e
--max-Parents = -1 (números negativos denotam nenhum limite superior).
--primeiro pai
Siga apenas o primeiro commit pai ao ver um commit de mesclagem. Esta opção pode dar um
melhor visão geral ao visualizar a evolução de um ramo de tópico específico, porque
mescla em um ramo de tópico tendem a ser apenas sobre o ajuste para upstream atualizado de
de vez em quando, e esta opção permite que você ignore os commits individuais trazidos
à sua história por meio de tal fusão. Não pode ser combinado com --bisect.
--não
Inverte o significado do ^ prefixo (ou falta dele) para todas as revisões seguintes
especificadores, até o próximo --não.
--tudo
Finja que todos os refs em refs / estão listados na linha de comando como .
--branches [= ]
Finja que todos os refs em refs / heads estão listados na linha de comando como .
If é fornecido, limita as ramificações àquelas que combinam com o glob do shell fornecido. Se padrão
falta ?, *, ou [, /* no final está implícito.
--tags [= ]
Finja que todos os refs em refs / tags estão listados na linha de comando como . Se
é fornecido, limita as tags àquelas correspondentes ao shell glob. Se faltar padrão ?,
*, ou [, /* no final está implícito.
--remotes [= ]
Finja que todos os refs em refs / remotes estão listados na linha de comando como .
If é fornecido, limite os branches de rastreamento remoto àqueles que correspondem ao shell fornecido
glob. Se faltar padrão ?, *, ou [, /* no final está implícito.
--glob =
Finja que todos os refs combinam com o shell glob estão listados no
linha de comando como . Principal refs /, é adicionado automaticamente se estiver faltando. Se
falta padrão ?, *, ou [, /* no final está implícito.
--exclude =
Não inclua correspondência de referências que o próximo --all, --branches, --tags,
--remotes ou --glob consideraria caso contrário. As repetições desta opção se acumulam
padrões de exclusão até o próximo --all, --branches, --tags, --remotes ou --glob
opção (outras opções ou argumentos não limpam os padrões acumulados).
Os padrões fornecidos não devem começar com refs / heads, refs / tags ou refs / remotes quando
aplicado a --branches, --tags ou --remotes, respectivamente, e eles devem começar com
refs / quando aplicado a --glob ou --all. Se um rastro /* é pretendido, deve ser dado
explicitamente.
--reflog
Finja que todos os objetos mencionados por reflogs estão listados na linha de comando como
.
--ignore-faltando
Ao ver um nome de objeto inválido na entrada, finja que a entrada incorreta não foi
dado.
-- bissectar
Finja como se a bissecção refs / bissecionar / ruim estivesse listada e como se fosse
seguido por --not e a bissecção good refs refs / bisect / good- * na linha de comando.
Não pode ser combinado com --first-parent.
--stdin
Além do listados na linha de comando, leia-os no padrão
entrada. Se um -- separador for visto, pare de ler commits e comece a ler caminhos para
limitar o resultado.
--marca cereja
Como --cherry-pick (veja abaixo), mas marque os commits equivalentes com = ao invés de omitir
eles, e os diferentes com +.
--colher cerejas
Omita qualquer commit que introduza a mesma mudança que outro commit do “outro lado”
quando o conjunto de confirmações é limitado com diferença simétrica.
Por exemplo, se você tem dois branches, A e B, uma maneira usual de listar todos os commits em
apenas um lado deles está com --left-right (veja o exemplo abaixo na descrição
da opção --esquerda-direita). No entanto, mostra os commits que foram escolhidos a dedo
do outro ramo (por exemplo, "3º na b" pode ser selecionado do ramo A).
Com esta opção, tais pares de commits são excluídos da saída.
- somente à esquerda, - somente à direita
Listar apenas confirma no respectivo lado de um intervalo simétrico, ou seja, apenas aqueles que
seria marcado como <resp. > por --esquerda-direita.
Por exemplo, --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, --cherry-pick --right-only --no-merges dá o
lista exata.
--cereja
Um sinônimo para --right-only --cherry-mark --no-merges; útil para limitar a saída para
os commits do nosso lado e marcar aqueles que foram aplicados do outro lado de um
história bifurcada com git log --cherry upstream ... mybranch, semelhante a git cherry
mybranch rio acima.
-g, --walk-reflogs
Em vez de percorrer a cadeia de ancestralidade do commit, percorra as entradas de reflog do mais recente
um para os mais velhos. Quando esta opção é usada você não pode especificar commits para excluir
(isso é, ^ commit, commit1..commit2 e commit1 ... commit2 notações não podem ser usadas).
Com o formato --pretty diferente do oneline (por razões óbvias), isso faz com que a saída
ter duas linhas extras de informações retiradas do reflog. Por padrão, commit @ {enésimo}
a notação é usada na saída. Quando o commit inicial é especificado como comprometa-se @ {agora},
saída também usa commit @ {timestamp} notação em vez disso. Em --pretty = oneline, o
a mensagem de confirmação é prefixada com essas informações na mesma linha. Esta opção não pode
ser combinado com --reverse. Veja também git-reflog(1).
--mesclar
Após uma falha na fusão, mostre os árbitros que afetam os arquivos que estão em conflito e não existem em
todas as cabeças devem ser mescladas.
--fronteira
Saída de commits de limite excluídos. Os commits de limite são prefixados com -.
História simplificação
Às vezes você está interessado apenas em partes da história, por exemplo, os commits
modificando um particular . Mas existem duas partes de História simplificação, uma parte
é selecionar os commits e a outra é como fazê-lo, pois existem várias estratégias para
simplificar a história.
As seguintes opções selecionam os commits a serem mostrados:
Compromete-se a modificar o dado são selecionados.
- simplificar por decoração
Os commits que são referidos por algum branch ou tag são selecionados.
Observe que commits extras podem ser mostrados para fornecer um histórico significativo.
As seguintes opções afetam a forma como a simplificação é realizada:
Modo padrão
Simplifica a história para a história mais simples explicando o estado final da árvore.
Mais simples porque remove alguns ramos laterais se o resultado final for o mesmo (ou seja,
mesclando filiais com o mesmo conteúdo)
- história completa
Igual ao modo padrão, mas não remove parte do histórico.
--denso
Apenas os commits selecionados são mostrados, mais alguns para ter um histórico significativo.
--escasso
Todos os commits no histórico simplificado são mostrados.
--simplify-merge
Opção adicional para --full-history para remover algumas mesclagens desnecessárias do resultado
histórico, já que não há commits selecionados contribuindo para esta fusão.
--caminho de ancestralidade
Quando é fornecido um intervalo de commits para exibir (por exemplo, commit1..commit2 or compromisso2 ^ commit1),
exibir apenas commits que existem diretamente na cadeia de ancestralidade entre os compromisso1 e
compromisso2, ou seja, confirmações que são descendentes de compromisso1, e ancestrais de compromisso2.
Segue uma explicação mais detalhada.
Suponha que você especificou foo como o . Devemos chamar commits que modificam foo! TREESAME,
e o resto TREESAME. (Em um diff filtrado por foo, eles parecem diferentes e iguais,
respectivamente.)
A seguir, sempre nos referiremos ao mesmo exemplo de história para ilustrar o
diferenças entre as configurações de simplificação. Presumimos que você esteja filtrando por um arquivo
foo neste gráfico de confirmação:
.-A --- M --- N --- O --- P --- Q
/ / / / / /
IBCDEY
\ / / / / /
`------------- 'X
A linha horizontal do histórico A --- Q é considerada o primeiro pai de cada fusão. o
commits são:
· I é o commit inicial, no qual existe foo com conteúdo “asdf”, e um arquivo quux
existe com conteúdo “quux”. Os commits iniciais são comparados a uma árvore vazia, então eu estou
! TREESAME.
· Em A, foo contém apenas “foo”.
· B contém a mesma mudança que A. Sua fusão M é trivial e, portanto, TREESAME para todos
pais.
· C não muda foo, mas sua mesclagem N muda para "foobar", então não é TREESAME
a qualquer pai.
· D define foo para “baz”. Sua fusão O combina as cordas de N e D a “foobarbaz”;
ou seja, não é TREESAME para nenhum dos pais.
· E muda quux para “xyzzy”, e sua fusão P combina as cordas para “quux xyzzy”. P é
TREESAME para O, mas não para E.
· X é um commit de raiz independente que adicionou um novo lado do arquivo e Y o modificou. Y é
TREESAME para X. Sua fusão Q adicionou lado a P, e Q é TREESAME para P, mas não para Y.
rev-list caminha para trás através da história, incluindo ou excluindo commits com base em
--full-history e / ou reescrita dos pais (via --parents ou --children) são usados. o
as seguintes configurações estão disponíveis.
Modo padrão
As confirmações são incluídas se não forem TREESAME para nenhum dos pais (embora isso possa ser
alterado, consulte --sparse abaixo). Se o commit foi uma fusão e foi TREESAME para um
pai, siga apenas esse pai. (Mesmo se houver vários pais TREESAME, siga
apenas um deles.) Caso contrário, siga todos os pais.
Isto resulta em:
.-A --- N --- O
///
EU IRIA
Observe como a regra para seguir apenas o pai TREESAME, se houver um disponível, removeu B
de consideração inteiramente. C foi considerado por meio de N, mas é TREESAME. Root commits
são comparados a uma árvore vazia, então eu sou! TREESAME.
As relações pai / filho são visíveis apenas com --parents, mas isso não afeta o
commits selecionados no modo padrão, então nós mostramos as linhas pai.
- história completa sem reescrita pelos pais
Este modo difere do padrão em um ponto: sempre siga todos os pais de uma fusão,
mesmo que seja TREESAME para um deles. Mesmo que mais de um lado da fusão tenha
commits incluídos, isso não significa que o merge em si seja! No
exemplo, nós temos
IABNDOPQ
M foi excluído porque é TREESAME para ambos os pais. E, C e B foram todos percorridos,
mas apenas B era! TREESAME, então os outros não aparecem.
Observe que sem a reescrita dos pais, não é realmente possível falar sobre o
relacionamentos pai / filho entre os commits, então os mostramos desconectados.
- história completa com reescrita dos pais
Os commits comuns são incluídos apenas se forem! TREESAME (embora isso possa ser alterado,
veja --sparse abaixo).
As mesclagens são sempre incluídas. No entanto, sua lista de pais é reescrita: ao longo de cada
pai, podar os commits que não estão incluídos. Isto resulta em
.-A --- M --- N --- O --- P --- Q
/ / / / /
IB / D /
\ / / / /
`------------- '
Compare com --full-history sem reescrever acima. Observe que E foi podado porque
é TREESAME, mas a lista pai de P foi reescrita para conter o pai I. de E
o mesmo aconteceu para C e N, e X, Y e Q.
Além das configurações acima, você pode alterar se TREESAME afeta a inclusão:
--denso
As confirmações percorridas são incluídas se não forem TREESAME para nenhum dos pais.
--escasso
Todos os commits percorridos são incluídos.
Observe que sem --full-history, isso ainda simplifica as mesclagens: se um dos pais
é TREESAME, seguimos apenas aquele, então os outros lados da mesclagem nunca são
caminhou.
--simplify-merge
Primeiro, construa um gráfico de histórico da mesma maneira que --full-history com reescrita do pai
faz (veja acima).
Em seguida, simplifique cada commit C para sua substituição C 'no histórico final de acordo com
as seguintes regras:
· Defina C 'para C.
· Substitua cada pai P de C 'com sua simplificação P'. No processo, largue
pais que são ancestrais de outros pais ou que são root enviam TREESAME para
uma árvore vazia e remova duplicatas, mas tome cuidado para nunca eliminar todos os pais que
nós somos TREESAME para.
· Se após esta reescrita do pai, C 'é uma raiz ou consolidação de mesclagem (tem zero ou> 1
pais), um commit de limite ou! TREESAME, ele permanece. Caso contrário, é substituído
com seu único pai.
O efeito disso é melhor mostrado comparando-se com --full-history com parent
reescrevendo. O exemplo se transforma em:
.-A --- M --- N --- O
///
IBD
\/ /
`--------- '
Observe as principais diferenças em N, P e Q ao longo de - história completa:
· A lista de pais de N eu removi, porque é um ancestral do outro pai M.
Ainda assim, N permaneceu porque é! TREESAME.
· A lista de pais de P da mesma forma que eu removi. P foi então removido completamente, porque
teve um dos pais e é TREESAME.
· A lista pai de Q tinha Y simplificado para X. X foi então removido, porque era um
Raiz TREESAME. Q foi então removido completamente, porque tinha um dos pais e é
MESMA DE ÁRVORE.
Finalmente, há um quinto modo de simplificação disponível:
--caminho de ancestralidade
Limite os commits exibidos para aqueles diretamente na cadeia de ancestrais entre o "de"
e "para" confirma no intervalo de confirmação fornecido. Ou seja, apenas exibem commits que são
ancestral do commit “para” e descendentes do commit “de”.
Como um exemplo de caso de uso, considere o seguinte histórico de commits:
D --- E ------- F
/\\
B --- C --- G --- H --- I --- J
/\
A ------- K --------------- L - M
Um regular D..M calcula o conjunto de commits que são ancestrais de M, mas exclui o
aqueles que são ancestrais de D. Isso é útil para ver o que aconteceu com a história
levando a M desde D, no sentido de que “o que M tem que não existia em D”.
O resultado neste exemplo seria todos os commits, exceto A e B (e o próprio D, de
curso).
Quando queremos descobrir quais commits em M estão contaminados com o bug introduzido por
D e precisa de conserto, no entanto, podemos querer visualizar apenas o subconjunto de D..M Que é
na verdade, descendentes de D, ou seja, excluindo C e K. Isso é exatamente o que
A opção --ancestry-path sim. Aplicado ao D..M intervalo, resulta em:
E ------- F
\\
G --- H --- I --- J
\
L - M
A opção --simplify-by-decoration permite que você veja apenas o quadro geral do
topologia do histórico, omitindo commits que não são referenciados por tags. Compromissos são
marcado como! TREESAME (em outras palavras, mantido após as regras de simplificação do histórico descritas
acima) se (1) eles são referenciados por tags, ou (2) eles mudam o conteúdo dos caminhos
fornecido na linha de comando. Todos os outros commits são marcados como TREESAME (sujeito a ser
simplificado).
COMPROMETA-SE Encomendar
Por padrão, os commits são mostrados em ordem cronológica reversa.
--data-ordem
Não mostre os pais antes que todos os seus filhos sejam mostrados, mas caso contrário, mostre os commits em
o pedido de carimbo de data / hora de confirmação.
--autor-data-ordem
Não mostre os pais antes que todos os seus filhos sejam mostrados, mas caso contrário, mostre os commits em
a ordem do carimbo de data / hora do autor.
--topo-ordem
Não mostre os pais antes que todos os seus filhos sejam mostrados e evite mostrar commits em
múltiplas linhas de história misturadas.
Por exemplo, em um histórico de commits como este:
--- 1 ---- 2 ---- 4 ---- 7
\\
3 ---- 5 ---- 6 ---- 8 ---
onde os números denotam a ordem dos carimbos de data / hora do commit, git rev-list e amigos com
--date-order mostra os commits na ordem do carimbo de data / hora: 8 7 6 5 4 3 2 1.
Com --topo-order, eles mostrariam 8 6 5 3 7 4 2 1 (ou 8 7 4 2 6 5 3 1); alguns mais velhos
commits são mostrados antes dos mais novos, a fim de evitar mostrar os commits de dois
trilha de desenvolvimento paralela misturada.
--marcha ré
Produza os commits na ordem reversa. Não pode ser combinado com --walk-reflogs.
objeto Traversal
Essas opções são voltadas principalmente para empacotamento de repositórios Git.
--no-walk [= (classificado | não classificado)]
Mostra apenas os commits fornecidos, mas não atravessa seus ancestrais. Isso não tem efeito
se um intervalo for especificado. Se o argumento unsorted for fornecido, os commits são mostrados em
a ordem em que foram dados na linha de comando. Caso contrário (se classificado ou nenhum argumento foi
dado), os commits são mostrados em ordem cronológica reversa por tempo de commit. Não pode ser
combinado com --graph.
- caminhar
Substitui um --no-walk anterior.
COMPROMETA-SE formatação
--pretty [= ], --format =
Imprima o conteúdo dos logs de commit em um determinado formato, onde pode ser
um de uma linha, baixo, média, completa, mais cheio, email, cru, formato: e
tformat:. Quando não é nenhuma das opções acima, e tem % placeholder nele, isso
age como se --pretty = tformat: foram dados.
Consulte a seção "FORMATOS BONITOS" para alguns detalhes adicionais para cada formato. Quando
= parte é omitida, o padrão é média.
Nota: você pode especificar o formato bonito padrão na configuração do repositório (veja
git-config(1)).
--abrev-commit
Em vez de mostrar o nome completo do objeto de confirmação hexadecimal de 40 bytes, mostre apenas um
prefixo parcial. O número não padrão de dígitos pode ser especificado com "--abbrev = "
(que também modifica a saída diff, se for exibida).
Isso deve tornar "--pretty = oneline" muito mais legível para pessoas que usam
Terminais de 80 colunas.
--no-abbrev-commit
Mostra o nome completo do objeto de confirmação hexadecimal de 40 bytes. Isso nega --abbrev-commit e
as opções que o implicam, como "--oneline". Ele também substitui o
log.abrevCommit variável.
--uma linha
Este é um atalho para "--pretty = oneline --abbrev-commit" usado junto.
--encoding =
Os objetos de confirmação registram a codificação usada para a mensagem de log em sua codificação
cabeçalho; esta opção pode ser usada para dizer ao comando para recodificar a mensagem de log de confirmação
na codificação preferida pelo usuário. Para comandos que não sejam de encanamento, o padrão é
UTF-8. Observe que, se um objeto afirma ser codificado em X e estamos emitindo em X, nós
produzirá o objeto na íntegra; isso significa que sequências inválidas no original
commit pode ser copiado para a saída.
--notes [= ]
Mostrar as notas (ver notas do git(1)) que anotam o commit, ao mostrar o commit
mensagem de registro. Este é o padrão para os comandos git log, git show e git whatchanged
quando não há opção --pretty, --format ou --oneline fornecida na linha de comando.
Por padrão, as notas mostradas são das referências de notas listadas no core.notesRef e
notas.displayRef variáveis (ou substituições de ambiente correspondentes). Ver git-config(1).
para mais detalhes.
Com um opcional argumento, mostre estas notas ref em vez das notas padrão
ref (s). O ref especifica o refname completo quando começa com refs / notes /; Quando
começa com notas /, refs / e, caso contrário, refs / notas / é prefixado para formar um nome completo de
a ref.
Várias opções de notas podem ser combinadas para controlar quais notas estão sendo exibidas.
Exemplos: "--notes = foo" mostrará apenas notas de "refs / notes / foo"; "--notes = foo
--notes "mostrará ambas as notas de" refs / notes / foo "e das notas padrão ref (s).
- sem notas
Não mostre notas. Isso nega a opção --notes acima, redefinindo a lista de
notas referências a partir das quais as notas são mostradas. As opções são analisadas na ordem fornecida no
linha de comando, então por exemplo "--notes --notes = foo --no-notes --notes = bar" mostrará apenas
notas de "refs / notas / barra".
--show-notes [= ], - [sem-] notas padrão
Essas opções estão obsoletas. Use as opções --notes / - no-notes acima.
--show-assinatura
Verifique a validade de um objeto de confirmação assinado passando a assinatura para gpg --verify
e mostrar a saída.
--data-relativa
Sinônimo para --date = relative.
--date =
Só tem efeito para datas mostradas em formato legível, como ao usar
--bonito. A variável de configuração log.date define um valor padrão para o --date do comando log
opção. Por padrão, as datas são mostradas no fuso horário original (do committer ou
autor). Se -local for anexado ao formato (por exemplo, iso-local), o local do usuário
fuso horário é usado em seu lugar.
--date = relative mostra as datas relativas à hora atual, por exemplo, “2 horas atrás”. o
A opção -local não pode ser usada com --raw ou --relative.
--date = local é um apelido para --date = default-local.
--date = iso (ou --date = iso8601) mostra carimbos de data / hora em um formato semelhante ao ISO 8601. o
as diferenças em relação ao formato estrito ISO 8601 são:
· Um espaço em vez do delimitador de data / hora T
· Um espaço entre o tempo e o fuso horário
· Sem dois pontos entre horas e minutos do fuso horário
--date = iso-strict (ou --date = iso8601-strict) mostra carimbos de data / hora em estrito ISO 8601
formato.
--date = rfc (ou --date = rfc2822) mostra carimbos de data / hora no formato RFC 2822, frequentemente encontrado em
mensagens de e-mail.
--date = short mostra apenas a data, mas não a hora, no formato AAAA-MM-DD.
--date = raw mostra a data no formato Git bruto interno formato% s% z.
--date = format: ... alimenta o formato ... para o strftime do seu sistema. Use --date = format:% c
para mostrar a data no formato preferido de sua localidade do sistema. Veja o manual do strftime para
uma lista completa de marcadores de posição de formato. Ao usar -local, a sintaxe correta é
--date = format-local: ....
--date = default é o formato padrão e é semelhante a --date = rfc2822, com alguns
exceções:
· Não há vírgula após o dia da semana
· O fuso horário é omitido quando o fuso horário local é usado
--pais
Imprime também os pais do commit (na forma "commit parent ..."). Também habilita
pai reescrevendo, veja História simplificação abaixo.
--crianças
Imprime também os filhos do commit (na forma "commit child ..."). Também habilita
pai reescrevendo, veja História simplificação abaixo.
--esquerda direita
Marque de qual lado de uma diferença simétrica um commit pode ser alcançado. Compromissos da esquerda
lado são prefixados com <e os da direita com>. Se combinado com --boundary,
esses commits são prefixados com -.
Por exemplo, se você tiver esta topologia:
y --- b --- b ramo B
/\/
/.
/ / \
o --- x --- a --- um ramo A
você obteria uma saída como esta:
$ git rev-list --left-right --boundary --pretty = oneline A ... B
> bbbbbbb ... 3º em b
> bbbbbbb ... 2º em b
<aaaaaa... 3º em um
<aaaaaa... 2º em um
-yyyyyyy ... primeiro em b
-xx... 1º em um
--gráfico
Desenhe uma representação gráfica baseada em texto do histórico de commits no lado esquerdo
da saída. Isso pode fazer com que linhas extras sejam impressas entre os commits, para
para que o histórico do gráfico seja desenhado corretamente. Não pode ser combinado com --no-walk.
Isso permite a reescrita dos pais, consulte História simplificação abaixo.
Isso implica a opção --topo-order por padrão, mas a opção --date-order também pode
ser especificado.
--show-linear-break [= ]
Quando --graph não é usado, todos os ramos do histórico são achatados, o que pode dificultar
veja que os dois commits consecutivos não pertencem a um branch linear. Esta opção
coloca uma barreira entre eles nesse caso. Se é especificado, é o
string que será mostrada em vez do padrão.
Dif formatação
Listadas abaixo estão as opções que controlam a formatação da saída do diff. Alguns deles são
específico a lista de rev-git(1), entretanto, outras opções de diferenças podem ser fornecidas. Ver git-diff-
arquivos(1) para mais opções.
-c
Com esta opção, a saída diff para um commit de mesclagem mostra as diferenças de cada um
os pais para o resultado de mesclagem simultaneamente em vez de mostrar diferenças de pares
entre um dos pais e o resultado, um de cada vez. Além disso, ele lista apenas os arquivos que
foram modificados de todos os pais.
--cc
Este sinalizador implica a opção -c e comprime ainda mais a saída do patch omitindo
pedaços desinteressantes cujos conteúdos nos pais têm apenas duas variantes e a fusão
resultado escolhe um deles sem modificação.
-m
Este sinalizador faz com que os commits de mesclagem mostrem a diferença completa como os commits regulares; para cada
mesclar pai, uma entrada de log separada e diff são gerados. Uma exceção é que apenas
diff contra o primeiro pai é mostrado quando a opção --first-pai é fornecida; naquilo
caso, a saída representa as mudanças que a fusão trouxe para dentro o então atual
ramo.
-r
Mostrar diferenças recursivas.
-t
Mostre os objetos da árvore na saída do diff. Isso implica em -r.
BONITO FORMATOS
Se o commit for uma fusão, e se o formato bonito não for uma linha, email or cru, um
linha adicional é inserida antes do Autor: linha. Esta linha começa com "Merge:" e
os sha1s de commits ancestrais são impressos, separados por espaços. Observe que o listado
commits podem não ser necessariamente a lista dos diretamente pai se compromete se você tiver limitado
sua visão da história: por exemplo, se você está interessado apenas nas mudanças relacionadas a um
determinado diretório ou arquivo.
Existem vários formatos integrados e você pode definir formatos adicionais definindo um
bonito. opção de configuração para outro nome de formato ou um formato: string, como
descrito abaixo (ver git-config(1)). Aqui estão os detalhes dos formatos integrados:
· uma linha
Ele foi projetado para ser o mais compacto possível.
· baixo
comprometer-se
Autor:
· média
comprometer-se
Autor:
Encontro:
· completa
comprometer-se
Autor:
Comprometer-se:
· mais cheio
comprometer-se
Autor:
AuthorDate:
Comprometer-se:
CommitDate:
A partir de
A partir de:
Encontro:
Assunto: [PATCH]
· cru
O cru formato mostra o commit inteiro exatamente como armazenado no objeto de commit.
Notavelmente, os SHA-1s são exibidos por completo, independentemente de se --abbrev ou
--no-abbrev são usados, e pais informações mostram os verdadeiros commits dos pais, sem
levando em conta os enxertos ou a simplificação da história. Observe que este formato afeta
a forma como os commits são exibidos, mas não a forma como o diff é mostrado, por exemplo, com o log do git
--cru. Para obter os nomes completos dos objetos em um formato diff bruto, use --no-abbrev.
· formato:
O formato: formato permite que você especifique quais informações você deseja mostrar.
Ele funciona um pouco como o formato printf, com a notável exceção de que você obtém um
nova linha com %n em vez de \n.
Por exemplo, formato: "O autor of %h foi %um, % ar% nThe título foi >>% s <<% n " iria mostrar
algo assim:
O autor de fe6e0ee foi Junio C Hamano, 23 horas atrás
O título era >> t4119: test autocomputing -p para entrada diferencial tradicional. <
Os marcadores de posição são:
· %H: confirmar hash
· %h: hash de confirmação abreviado
· %T: hash de árvore
· %t: hash de árvore abreviado
· %P: hashes dos pais
· %p: hashes parentes abreviados
· %um: nome do autor
· %um: nome do autor (respeitando .mailmap, veja git-shortlog(1) ou culpa(1))
· % ae: email do autor
· % aE: e-mail do autor (respeitando .mailmap, consulte git-shortlog(1) ou culpa(1))
· %de Anúncios: data do autor (o formato respeita --data = opção)
· %de Anúncios: data do autor, estilo RFC2822
· % ar: data do autor, parente
· %no: data do autor, carimbo de data / hora UNIX
· % ai: data do autor, formato semelhante ao ISO 8601
· % aI: data do autor, formato estrito ISO 8601
· % cn: nome do committer
· % cN: nome do committer (respeitando .mailmap, veja git-shortlog(1) ou culpa(1))
· % ce: email do committer
· % cE: email do committer (respeitando .mailmap, veja git-shortlog(1) ou culpa(1))
· %CD: data do committer (o formato respeita --date = opção)
· %CD: data do committer, estilo RFC2822
· % cr: data do committer, relativa
· % ct: data do committer, carimbo de data / hora UNIX
· % ci: data do committer, formato semelhante ao ISO 8601
· % cI: data do committer, formato ISO 8601 estrito
· %d: nomes de ref, como a opção --decorate de git-log(1).
· %D: nomes ref sem o invólucro "(", ")".
· %e: codificação
· %s: sujeito
· %f: linha de assunto limpa, adequada para um nome de arquivo
· %b: corpo
· %B: corpo bruto (assunto desembrulhado e corpo)
· %N: notas de commit
· % GG: mensagem de verificação bruta do GPG para um commit assinado
· % G?: mostre "G" para uma assinatura boa, "B" para uma assinatura ruim, "U" para uma assinatura boa,
assinatura não confiável e "N" para nenhuma assinatura
· % GS: mostra o nome do signatário para um commit assinado
· % GK: mostra a chave usada para assinar um commit assinado
· % gD: seletor de reflog, por exemplo, refs / stash @ {1}
· % gd: seletor de reflog encurtado, por exemplo, stash @ {1}
· % gn: nome da identidade do reflog
· % gN: nome da identidade reflog (respeitando .mailmap, consulte git-shortlog(1) ou git-
culpa(1))
· % ge: email de identidade de reflog
· % gE: e-mail de identidade de reflog (respeitando .mailmap, consulte git-shortlog(1) ou git-
culpa(1))
· % gs: assunto reflog
· % Cred: mudar a cor para vermelho
· % Cgreen: mudar a cor para verde
· % Cblue: mudar a cor para azul
· % Creset: redefinir cor
· % C (...): especificação de cor, conforme descrito em color.branch. * config option; adicionando
automático, no início emitirá cor apenas quando as cores estiverem habilitadas para saída de log
(por color.diff, color.ui ou --color, e respeitando as configurações automáticas do
ex se formos para um terminal). auto sozinho (ou seja,% C (automático)) ligará
coloração automática nos próximos espaços reservados até que a cor seja trocada novamente.
· %m: marca esquerda, direita ou limite
· %n: nova linha
· %%: um cru %
· % x00: imprime um byte de um código hexadecimal
· %C([ [, [, ]]]): troca de quebra de linha, como a opção -w de git-
shortlog(1).
· % <( [, trunc | ltrunc | mtrunc]): faça com que o próximo espaço reservado ocupe pelo menos N colunas,
espaços de preenchimento à direita, se necessário. Opcionalmente, truncar no início
(ltrunc), o meio (mtrunc) ou o final (trunc) se a saída for maior que N
colunas. Observe que o truncamento só funciona corretamente com N> = 2.
· % <| ( ): fazer com que o próximo espaço reservado leve pelo menos até as enésimas colunas, preenchimento
espaços à direita se necessário
· %> ( ), %> | ( ): igual a % <( ), % <| ( ) respectivamente, mas espaços de preenchimento
à esquerda
· % >> ( ), % >> | ( ): igual a %> ( ), %> | ( ) respectivamente, exceto que se o
próximo placeholder ocupa mais espaços do que os dados e há espaços à sua esquerda,
use esses espaços
· %> <( ), %> <| ( ): igual a % <( ), % <| ( ) respectivamente, mas preenchendo ambos
lados (ou seja, o texto é centralizado)
Observação
Alguns marcadores de posição podem depender de outras opções fornecidas ao mecanismo de passagem de revisão.
Por exemplo, as opções% g * reflog irão inserir uma string vazia, a menos que estejamos
atravessando entradas de reflog (por exemplo, por git log -g). Os marcadores de posição% d e% D usarão
o formato de decoração "curto" se --decorate ainda não foi fornecido no comando
linha.
Se você adicionar um + (sinal de mais) após % de um espaço reservado, um feed de linha é inserido imediatamente
antes da expansão se e somente se o espaço reservado se expandir para uma string não vazia.
Se você adicionar um - (sinal de menos) após % de um espaço reservado, feeds de linha que precedem imediatamente
a expansão é excluída se e somente se o espaço reservado se expandir para uma string vazia.
Se você adicionar um `` (espaço) após % de um placeholder, um espaço é inserido imediatamente antes
a expansão se e somente se o espaço reservado se expandir para uma string não vazia.
· formato:
O formato: formato funciona exatamente como formato:, exceto que fornece "terminador"
semântica em vez de semântica "separadora". Em outras palavras, cada commit tem o
caractere terminador de mensagem (geralmente uma nova linha) acrescentado, em vez de um separador
colocado entre as entradas. Isso significa que a entrada final de um formato de linha única
ser devidamente encerrado com uma nova linha, assim como o formato "oneline". Para
exemplo:
$ git log -2 --pretty = format:% h 4da45bef \
| perl -pe '$ _. = "- SEM NEWLINE \ n" a menos que / \ n /'
4da45be
7134973 - SEM NEWLINE
$ git log -2 --pretty = tformat:% h 4da45bef \
| perl -pe '$ _. = "- SEM NEWLINE \ n" a menos que / \ n /'
4da45be
7134973
Além disso, qualquer string não reconhecida que contenha um% é interpretada como se tivesse
tformat: na frente dele. Por exemplo, esses dois são equivalentes:
$ git log -2 --pretty = tformat:% h 4da45bef
$ git log -2 --pretty =% h 4da45bef
COMUM DIFF OPÇÕES
-p, -u, --patch
Gerar patch (consulte a seção sobre geração de patches).
-s, --sem patch
Suprime a saída do diff. Útil para comandos como git show que mostram o patch por
padrão, ou para cancelar o efeito de --patch.
-VOCÊ , --unified =
Gerar diffs com linhas de contexto em vez das três usuais. Implica -p.
--cru
Para cada confirmação, mostre um resumo das mudanças usando o formato diff bruto. Veja o "RAW
Seção OUTPUT FORMAT "de git-diff(1). Isso é diferente de mostrar o próprio log
no formato bruto, que você pode obter com --format = raw.
--patch-com-raw
Sinônimo para -p --raw.
--mínimo
Gaste mais tempo para garantir que a menor diferença possível seja produzida.
--paciência
Gere um diff usando o algoritmo "diff de paciência".
--histograma
Gere um diff usando o algoritmo "histograma diff".
--diff-algorithm = {pacience | minimal | histogram | myers}
Escolha um algoritmo diff. As variantes são as seguintes:
padrão, myers
O algoritmo básico de diff ganancioso. Atualmente, este é o padrão.
mínimo
Gaste mais tempo para garantir que a menor diferença possível seja produzida.
paciência
Use o algoritmo de "diferença de paciência" ao gerar patches.
Histograma
Este algoritmo estende o algoritmo de paciência para "apoiar o comum de baixa ocorrência
elementos ".
Por exemplo, se você configurou a variável diff.algorithm para um valor não padrão e
deseja usar o padrão, então você deve usar a opção --diff-algorithm = default.
--stat [= [, [, ]]]
Gere um diffstat. Por padrão, tanto espaço quanto necessário será usado para o
parte do nome do arquivo e o resto da parte do gráfico. Largura máxima padronizada para terminal
largura, ou 80 colunas se não estiver conectado a um terminal, e pode ser substituído por .
A largura da parte do nome do arquivo pode ser limitada dando outra largura
depois de uma vírgula. A largura da parte do gráfico pode ser limitada usando
--stat-graph-width = (afeta todos os comandos gerando um gráfico estatístico) ou por
configuração diff.statGraphWidth = (não afeta o patch de formato git). Dando um
terceiro parâmetro , você pode limitar a saída ao primeiro linhas, seguidas
por ... se houver mais.
Esses parâmetros também podem ser definidos individualmente com --stat-width = ,
--stat-name-width = e --stat-count = .
--numstat
Semelhante a --stat, mas mostra o número de linhas adicionadas e excluídas em notação decimal e
nome do caminho sem abreviatura, para torná-lo mais amigável à máquina. Para arquivos binários,
produz dois - em vez de dizer 0 0.
--shortstat
Produz apenas a última linha do formato --stat contendo o número total de modificados
arquivos, bem como o número de linhas adicionadas e excluídas.
--dirstat [= ]
Produza a distribuição da quantidade relativa de mudanças para cada subdiretório. o
o comportamento de --dirstat pode ser personalizado passando-lhe uma lista separada por vírgulas de
parâmetros. Os padrões são controlados pela variável de configuração diff.dirstat
(Vejo git-config(1)). Os seguintes parâmetros estão disponíveis:
alterar
Calcule os números dirstat contando as linhas que foram removidas do
origem ou adicionado ao destino. Isso ignora a quantidade de código puro
movimentos dentro de um arquivo. Em outras palavras, reorganizar as linhas em um arquivo não é
contado tanto quanto outras mudanças. Este é o comportamento padrão quando nenhum parâmetro
é dada.
linhas
Calcule os números dirstat fazendo a análise de diff baseada em linha regular, e
somando as contagens de linhas removidas / adicionadas. (Para arquivos binários, conte blocos de 64 bytes
em vez disso, uma vez que os arquivos binários não têm um conceito natural de linhas). Este é um mais
caro --dirstat comportamento do que mudanças de comportamento, mas conta
linhas reorganizadas dentro de um arquivo tanto quanto outras alterações. A saída resultante é
consistente com o que você obtém dos outros - * opções de estatísticas.
arquivos
Calcule os números do dirstat contando o número de arquivos alterados. Cada um mudou
arquivo conta igualmente na análise dirstat. Este é o mais barato computacionalmente
Comportamento --dirstat, uma vez que não tem que ver o conteúdo do arquivo de forma alguma.
acumulativo
Contar alterações em um diretório filho para o diretório pai também. Observe que
no caso de uso cumulativo, a soma dos percentuais informados pode ser superior a 100%. o
o comportamento padrão (não cumulativo) pode ser especificado com o não cumulativo
parâmetro.
Um parâmetro inteiro especifica uma porcentagem de corte (3% por padrão). Diretórios
contribuindo com menos do que esta porcentagem das mudanças não são mostradas na saída.
Exemplo: o seguinte contará os arquivos alterados, enquanto ignora os diretórios com menos
de 10% da quantidade total de arquivos alterados e acumulando contagens de diretório filho
nos diretórios pai: --dirstat = arquivos, 10, cumulativo.
--resumo
Produza um resumo condensado de informações de cabeçalho estendidas, como criações, renomeações
e mudanças de modo.
--patch-com-stat
Sinônimo de -p --stat.
-z
Separe os commits com NULs em vez de novas linhas.
Além disso, quando --raw ou --numstat for fornecido, não munge nomes de caminho e use NULs como
terminadores de campo de saída.
Sem esta opção, cada saída de nome de caminho terá TAB, LF, aspas duplas e
caracteres de barra invertida substituídos por \ t, \ n, \ "e \\, respectivamente, e o nome do caminho
será colocado entre aspas duplas se alguma dessas substituições ocorrer.
- apenas nome
Mostra apenas os nomes dos arquivos alterados.
--nome-status
Mostra apenas nomes e status dos arquivos alterados. Veja a descrição do --diff-filter
opção sobre o significado das letras de status.
--submodule [= ]
Especifique como as diferenças nos submódulos são mostradas. Quando --submodule ou --submodule = log
é dado, o log formato é usado. Este formato lista os commits no intervalo como git-
submódulo(1) o resumo sim. Omitindo a opção --submodule ou especificando
--submodule = short, usa o baixo formato. Este formato mostra apenas os nomes dos
confirma no início e no final do intervalo. Pode ser ajustado através do diff.submodule
configuração variável.
--color [= ]
Mostrar diferenças coloridas. --color (ou seja, sem =) é o mesmo que --color = always.
pode ser sempre, nunca ou automático.
- sem cor
Desative as diferenças coloridas. É o mesmo que --color = never.
--word-diff [= ]
Mostrar uma palavra diff, usando o para delimitar palavras alteradas. Por padrão, as palavras são
delimitado por espaços em branco; veja --word-diff-regex abaixo. o padrão para planície,
e deve ser um dos seguintes:
cor
Destaque as palavras alteradas usando apenas cores. Implica --color.
planície
Mostrar palavras como [-removed-] e {+ adicionado +}. Não faz nenhuma tentativa de escapar do
delimitadores se eles aparecerem na entrada, então a saída pode ser ambígua.
porcelana
Use um formato especial baseado em linha destinado ao consumo de script.
Execuções adicionadas / removidas / inalteradas são impressas no formato diff unificado usual,
começando com um caractere + / - / `` no início da linha e se estendendo para
O fim da linha. As novas linhas na entrada são representadas por um til ~ em uma linha
própria.
Nenhum
Desative a palavra diff novamente.
Observe que, apesar do nome do primeiro modo, a cor é usada para destacar o
peças em todos os modos, se habilitado.
--word-diff-regex =
Usar para decidir o que é uma palavra, em vez de considerar execuções de espaços não em branco para
seja uma palavra. Também implica --word-diff a menos que já esteja habilitado.
Cada correspondência não sobreposta do é considerada uma palavra. Qualquer coisa entre
essas correspondências são consideradas espaços em branco e ignoradas (!) para fins de localização
diferenças. Você pode querer acrescentar | [^ [: espaço:]] à sua expressão regular para fazer
certifique-se de que corresponda a todos os caracteres que não sejam espaços em branco. Uma correspondência que contém uma nova linha é
silenciosamente truncado (!) na nova linha.
Por exemplo, --word-diff-regex =. tratará cada caractere como uma palavra e,
correspondentemente, mostre as diferenças caractere por caractere.
O regex também pode ser definido por meio de um driver diff ou opção de configuração, consulte
gitatributes(1) ou git-config(1). Fornecê-lo substitui explicitamente qualquer driver diff ou
definição de configuração. Os drivers Diff substituem as definições de configuração.
--color-words [= ]
Equivalente a --word-diff = color plus (se um regex foi especificado)
--word-diff-regex = .
- sem renomear
Desative a detecção de renomeação, mesmo quando o arquivo de configuração fornece o padrão para fazer
assim.
--Verifica
Avisa se as alterações introduzem erros de espaço em branco. O que são considerados erros de espaço em branco é
controlado pela configuração core.whitespace. Por padrão, espaços em branco à direita
(incluindo linhas que consistem apenas em espaços em branco) e um caractere de espaço que é
imediatamente seguido por um caractere de tabulação dentro do recuo inicial da linha são
considerados erros de espaço em branco. Sai com status diferente de zero se forem encontrados problemas. Não
compatível com --exit-code.
--ws-error-highlight =
Destacar erros de espaço em branco nas linhas especificadas por na cor especificada por
color.diff.whitespace. é uma lista separada por vírgulas de contexto antigo e novo. Quando
esta opção não é fornecida, apenas os erros de espaço em branco nas novas linhas são realçados. Por exemplo
--ws-error-highlight = erros de espaço em branco de realces novos e antigos tanto excluídos quanto adicionados
linhas. todos podem ser usados como uma abreviatura para o contexto antigo, novo.
--índice completo
Em vez do primeiro punhado de caracteres, mostre o blob completo de pré e pós-imagem
nomes de objetos na linha "índice" ao gerar saída de formato de patch.
--binário
Além de --full-index, gera um diff binário que pode ser aplicado com git-apply.
--abbrev [= ]
Em vez de mostrar o nome completo do objeto hexadecimal de 40 bytes na saída do formato diff-raw
e linhas de cabeçalho diff-tree, mostram apenas um prefixo parcial. Isso é independente do
Opção --full-index acima, que controla o formato de saída do patch diff. Fora do padrão
número de dígitos pode ser especificado com --abbrev = .
-B [ ] [/ ], --break-rewrites [= [ ] [/ ]]
Divida as alterações de reescrita completas em pares de excluir e criar. Isso serve a dois
fins:
Afeta a forma como uma mudança equivale a uma reescrita total de um arquivo, não como uma série
de exclusão e inserção misturadas com muito poucas linhas que coincidem
textualmente como o contexto, mas como uma única exclusão de tudo o que era antigo seguido por um
inserção única de tudo novo, e o número m controla este aspecto do -B
opção (o padrão é 60%). -B / 70% especifica que menos de 30% do original deve
permanecem no resultado para o Git considerá-lo uma reescrita total (ou seja, caso contrário, o
patch resultante será uma série de deleção e inserção misturada com o contexto
linhas).
Quando usado com -M, um arquivo totalmente reescrito também é considerado como a fonte de um
renomear (normalmente -M considera apenas um arquivo que desapareceu como a fonte de uma renomeação),
e o número n controla este aspecto da opção -B (o padrão é 50%). -B20%
especifica que uma mudança com adição e exclusão em comparação com 20% ou mais do
o tamanho do arquivo é elegível para ser escolhido como uma possível fonte de uma renomeação para
outro arquivo.
-M [ ], --find-renames [= ]
Se estiver gerando diffs, detecte e relate renomeações para cada commit. Para os seguintes arquivos
através de renomeações enquanto percorre o histórico, consulte --seguir. Se n for especificado, é um
limite no índice de similaridade (ou seja, quantidade de adições / exclusões em comparação com o
tamanho do arquivo). Por exemplo, -M90% significa que o Git deve considerar um par excluir / adicionar como um
renomear se mais de 90% do arquivo não foi alterado. Sem o sinal%, o número é para
ser lido como uma fração, com um ponto decimal antes dele. Ou seja, -M5 torna-se 0.5 e é
portanto, o mesmo que -M50%. Da mesma forma, -M05 é igual a -M5%. Para limitar a detecção a
renomeações exatas, use -M100%. O índice de similaridade padrão é 50%.
-C [ ], --find-cópias [= ]
Detecta cópias e também renomeia. Veja também --find-cópias-mais difícil. Se n for especificado,
tem o mesmo significado que para -M .
--encontrar cópias-mais difícil
Por motivos de desempenho, por padrão, a opção -C encontra cópias apenas se o arquivo original
da cópia foi modificado no mesmo changeset. Este sinalizador faz com que o comando inspecione
arquivos não modificados como candidatos à fonte de cópia. Este é um muito caro
operação para grandes projetos, portanto, use-a com cuidado. Dando mais de uma opção -C
tem o mesmo efeito.
-D, --irreversível-delete
Omita a pré-imagem para exclusões, ou seja, imprima apenas o cabeçalho, mas não a diferença entre os
preimage e / dev / null. O patch resultante não deve ser aplicado com patch ou
git apply; isso é apenas para pessoas que desejam se concentrar apenas na revisão do
texto após a mudança. Além disso, a saída obviamente não tem informações suficientes para
aplique esse patch ao contrário, mesmo manualmente, daí o nome da opção.
Quando usado junto com -B, omite também a pré-imagem na parte de exclusão de um
excluir / criar par.
-eu
As opções -M e -C requerem tempo de processamento de O (n ^ 2), onde n é o número de
potencial renomear / copiar destinos. Esta opção evita que a detecção de renomeação / cópia seja executada
se o número de destinos de renomeação / cópia exceder o número especificado.
--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), têm seu tipo (ou seja, arquivo regular, link simbólico, submódulo, ...) alterado (T), são
Não mesclados (U), são desconhecidos (X) ou tiveram seu emparelhamento quebrado (B). Qualquer combinação
dos caracteres do filtro (incluindo nenhum) podem ser usados. Quando * (tudo ou nenhum) é adicionado
para a combinação, todos os caminhos são selecionados se houver algum arquivo que corresponda a outro
critérios na comparação; se não houver nenhum arquivo que corresponda a outros critérios, nada
é selecionado.
-S
Procure por diferenças que mudam o número de ocorrências da string especificada
(ou seja, adição / exclusão) em um arquivo. Destinado ao uso do criador de scripts.
É útil quando você está procurando por um bloco exato de código (como uma estrutura) e deseja
para saber a história desse bloco desde que ele surgiu: use o recurso
iterativamente para alimentar o bloco interessante na pré-imagem de volta para -S e continuar
até obter a primeira versão do bloco.
-G
Procure por diferenças cujo texto de patch contenha linhas adicionadas / removidas que correspondam .
Para ilustrar a diferença entre -S --pickaxe-regex e -G , considere
um commit com o seguinte diff no mesmo arquivo:
+ return! regexec (regexp, two-> ptr, 1, ®match, 0);
...
- hit =! regexec (regexp, mf2.ptr, 1, ®match, 0);
Enquanto git log -G "regexec \ (regexp" mostrará este commit, git log -S "regexec \ (regexp"
--pickaxe-regex não (porque o número de ocorrências dessa string não
mudança).
veja a picareta entrada em gitdiffcore(7) para mais informações.
--picareta-tudo
Quando -S ou -G encontra uma mudança, mostra todas as mudanças nesse conjunto de mudanças, não apenas o
arquivos que contêm a mudança em .
--pickaxe-regex
Trate o dado a -S como uma expressão regular POSIX estendida para corresponder.
-O
Produza o patch na ordem especificada no , que tem um shell glob
padrão por linha. Isso substitui a variável de configuração diff.orderFile (consulte git-
configuração(1)). Para cancelar diff.orderFile, use -O / dev / null.
-R
Troque duas entradas; ou seja, mostra diferenças de índice ou arquivo em disco para árvore
conteúdos.
--relative [= ]
Quando executado a partir de um subdiretório do projeto, pode ser solicitado a excluir alterações fora
o diretório e mostra os nomes de caminho relativos a ele com esta opção. Quando você não está em
um subdiretório (por exemplo, em um repositório vazio), você pode nomear qual subdiretório criar
a saída em relação a, dando um como um argumento.
-um texto
Trate todos os arquivos como texto.
--ignore-espaço-at-eol
Ignore as alterações nos espaços em branco no EOL.
-b, --ignore-mudança de espaço
Ignore as alterações na quantidade de espaços em branco. Isso ignora o espaço em branco no final da linha, e
considera todas as outras sequências de um ou mais caracteres de espaço em branco como equivalentes.
-w, --ignore-todo-o-espaço
Ignore os espaços em branco ao comparar as linhas. Isso ignora as diferenças, mesmo se uma linha tiver
espaço em branco onde a outra linha não tem nenhum.
--ignore-linhas em branco
Ignore as alterações cujas linhas estão todas em branco.
--inter-hunk-context =
Mostra o contexto entre os diferentes blocos, até o número especificado de linhas, assim
pedaços de fusão que estão próximos uns dos outros.
-W, --função-contexto
Mostrar funções de mudanças circundantes inteiras.
--ext-diff
Permitir que um auxiliar de diff externo seja executado. Se você definir um driver diff externo com
gitatributes(5), você precisa usar esta opção com git-log(1) e amigos.
--no-ext-diff
Proibir drivers diff externos.
--textconv, --no-textconv
Permitir (ou proibir) a execução de filtros de conversão de texto externos ao comparar binários
arquivos. Ver gitatributes(5) para obter detalhes. Porque os filtros textconv são tipicamente um
conversão unilateral, o diff resultante é adequado para consumo humano, mas não pode
ser aplicado. Por este motivo, os filtros textconv são ativados por padrão apenas para git-
diff(1) e git-log(1), mas não para patch de formato git(1) ou comandos de encanamento diff.
--ignore-submodules [= ]
Ignore as alterações nos submódulos na geração de diferenças. pode ser "nenhum",
"untracked", "dirty" ou "all", que é o padrão. Usar "nenhum" considerará o
submódulo modificado quando contém arquivos não rastreados ou modificados ou seu HEAD
difere do commit registrado no superprojeto e pode ser usado para substituir qualquer
configurações do ignorar opção em git-config(1) ou módulos git(5). Quando "não rastreado" é
submódulos usados não são considerados sujos quando contêm apenas conteúdo não rastreado (mas
eles ainda são verificados quanto a conteúdo modificado). Usar "sujo" ignora todas as mudanças no
árvore de trabalho de submódulos, apenas as mudanças nos commits armazenados no superprojeto são
mostrado (este era o comportamento até 1.7.0). Usar "todos" esconde todas as mudanças para
submódulos.
--src-prefix =
Mostra o prefixo de origem fornecido em vez de "a /".
--dst-prefix =
Mostra o prefixo de destino fornecido em vez de "b /".
- sem prefixo
Não mostre nenhum prefixo de origem ou destino.
Para obter uma explicação mais detalhada sobre essas opções comuns, consulte também gitdiffcore(7).
GERANDO REMENDAS COM -P
Quando "git-diff-index", "git-diff-tree" ou "git-diff-files" são executados com um -p opção, "git
diff "sem o --cru opção, ou "git log" com a opção "-p", eles não produzem o
saída descrita acima; em vez disso, eles produzem um arquivo de patch. Você pode personalizar a criação
de tais patches por meio das variáveis de ambiente GIT_EXTERNAL_DIFF e GIT_DIFF_OPTS.
O que a opção -p produz é ligeiramente diferente do formato diff tradicional:
1. É precedido por um cabeçalho "git diff" semelhante a este:
diff --git a / arquivo1 b / arquivo2
Os nomes de arquivo a / eb / são iguais, a menos que renomear / copiar esteja envolvido. Especialmente, mesmo
para uma criação ou exclusão, / dev / null é não usado no lugar do a / ou b /
nomes de arquivos.
Quando renomear / copiar está envolvido, arquivo1 e arquivo2 mostram o nome do arquivo de origem do
renomear / copiar e o nome do arquivo que a renomeação / cópia produz, respectivamente.
2. É seguido por uma ou mais linhas de cabeçalho estendidas:
modo antigo
novo modo
modo de arquivo excluído
novo modo de arquivo
copiar de
copiar para
renomear de
renomear para
índice de similaridade
índice de dissimilaridade
índice ..
Os modos de arquivo são impressos como números octais de 6 dígitos, incluindo o tipo de arquivo e o arquivo
bits de permissão.
Os nomes de caminho em cabeçalhos estendidos não incluem os prefixos a / e b /.
O índice de similaridade é a porcentagem de linhas inalteradas e o índice de dissimilaridade
é a porcentagem de linhas alteradas. É um número inteiro arredondado, seguido por um
sinal de porcentagem. O valor do índice de similaridade de 100% é, portanto, reservado para dois arquivos iguais,
enquanto 100% de dissimilaridade significa que nenhuma linha do arquivo antigo chegou ao novo
um.
A linha de índice inclui a soma de verificação SHA-1 antes e depois da alteração. o é
incluído se o modo de arquivo não mudar; caso contrário, linhas separadas indicam o antigo
e o novo modo.
3. Os caracteres TAB, LF, aspas duplas e barra invertida em nomes de caminho são representados como \ t, \ n,
\ "e \\, respectivamente. Se houver necessidade de tal substituição, o conjunto
o nome do caminho é colocado entre aspas duplas.
4. Todos os arquivos file1 na saída referem-se aos arquivos antes do commit, e todos os file2
arquivos referem-se a arquivos após o commit. É incorreto aplicar cada mudança a cada
arquivo sequencialmente. Por exemplo, este patch irá trocar a e b:
diff --git a / ab / b
renomear de um
renomear para b
diff --git a / bb / a
renomear de b
renomear para um
COMBINADO DIFF FORMATO
Qualquer comando gerador de diff pode ter a opção -c ou --cc para produzir um combinado diff quando
mostrando uma fusão. Este é o formato padrão ao mostrar mesclagens com git-diff(1) ou git-
mostrar(1). Observe também que você pode dar a opção -m a qualquer um desses comandos para forçar
geração de diffs com pais individuais de uma fusão.
A combinado diff formato é parecido com este:
diff --descrição combinada.c
índice 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)
{
+ char não assinado sha1 [20];
+ struct commit * cmit;
struct commit_list * list;
estático int inicializado = 0;
struct commit_name * n;
+ if (get_sha1 (arg, sha1) <0)
+ uso (describe_usage);
+ cmit = lookup_commit_reference (sha1);
+ if (! cmit)
+ uso (describe_usage);
+
if (! inicializado) {
inicializado = 1;
for_each_ref (get_name);
1. É precedido por um cabeçalho "git diff", que se parece com isto (quando -c opção
usava):
diff - arquivo combinado
ou assim (quando --cc opção é usada):
diff - arquivo cc
2. É seguido por uma ou mais linhas de cabeçalho estendidas (este exemplo mostra uma fusão com
dois pais):
índice , ..
modo , ..
novo modo de arquivo
modo de arquivo excluído ,
O modo , .. linha aparece apenas se pelo menos um dos é
diferente do resto. Cabeçalhos estendidos com informações sobre os conteúdos detectados
movimento (renomeação e detecção de cópia) são projetados para funcionar com diff de dois
e não são usados pelo formato diff combinado.
3. É seguido por um cabeçalho de arquivo / para arquivo de duas linhas
--- um arquivo
+++ b / arquivo
Semelhante ao cabeçalho de duas linhas para o tradicional unificado formato diff, / dev / null é usado para
sinalizar arquivos criados ou excluídos.
4. O formato do cabeçalho do bloco é modificado para evitar que as pessoas acidentalmente o alimentem
patch -p1. O formato diff combinado foi criado para revisão das alterações de consolidação de mesclagem, e
não foi feito para aplicar. A mudança é semelhante à mudança na extensão índice
cabeçalho:
@@@ @@@
Existem (número de pais + 1) caracteres @ no cabeçalho do bloco para o diff combinado
formato.
Ao contrário do tradicional unificado formato diff, que mostra dois arquivos A e B com um único
coluna que tem - (menos - aparece em A, mas removido em B), + (mais - ausente em A, mas
adicionado a B), ou prefixo "" (espaço - inalterado), este formato compara dois ou mais arquivos
arquivo1, arquivo2, ... com um arquivo X, e mostra como X difere de cada um dos arquivosN. Uma coluna
para cada arquivo, N é adicionado à linha de saída para observar como a linha de X é diferente de
.
O caractere A na coluna N significa que a linha aparece no arquivo N, mas não aparece
no resultado. Um caractere + na coluna N significa que a linha aparece no resultado,
e o arquivoN não tem essa linha (em outras palavras, a linha foi adicionada, a partir do ponto de
visão desse pai).
No exemplo de saída acima, a assinatura da função foi alterada em ambos os arquivos (portanto, dois
- remoções de arquivo1 e arquivo2, mais ++ para significar uma linha que foi adicionada não
aparecem em arquivo1 ou arquivo2). Além disso, oito outras linhas são as mesmas do arquivo 1, mas
não aparece no arquivo2 (portanto, prefixado com +).
Quando mostrado por git diff-tree -c, ele compara os pais de um commit de merge com o merge
resultado (ou seja, arquivo1..arquivoN são os pais). Quando mostrado por git diff-files -c, ele compara
os dois pais de fusão não resolvidos com o arquivo da árvore de trabalho (ou seja, o arquivo 1 é o estágio 2, também conhecido como
"nossa versão", o arquivo2 é o estágio 3, também conhecido como "sua versão").
EXEMPLOS
git log --no-merges
Mostra todo o histórico de commits, mas pula qualquer mesclagem
git log v2.6.12 .. include / scsi drivers / scsi
Mostrar todos os commits desde a versão v2.6.12 que alterou qualquer arquivo no include / scsi ou
subdiretórios drivers / scsi
git log --since = "2 semanas atrás" - gitk
Mostra as mudanças durante as últimas duas semanas no arquivo idiota. O “-” é necessário para
evite confusão com o ramo nomeado idiota
git log --name-status release..test
Mostra os commits que estão no branch "test", mas ainda não no branch "release",
junto com a lista de caminhos que cada confirmação modifica.
git log --seguir builtin / rev-list.c
Mostra os commits que mudaram builtin / rev-list.c, incluindo os commits que
ocorreu antes de o arquivo receber seu nome atual.
git log --branches --not --remotes = origin
Mostra todos os commits que estão em qualquer um dos ramos locais, mas não em nenhum de rastreamento remoto
ramos para origem (o que você tem essa origem não).
git log master --not --remotes = * / master
Mostra todos os commits que estão no mestre local, mas não em nenhum repositório mestre remoto
galhos.
git log -p -m --primeiro-pai
Mostra o histórico, incluindo diferenças de mudança, mas apenas da perspectiva do "ramo principal",
pulando commits que vêm de branches mesclados, e mostrando diferenças completas de mudanças
introduzidas pelas fusões. Isso faz sentido apenas ao seguir uma política estrita de
mesclar todas as ramificações de tópico ao permanecer em uma única ramificação de integração.
git log -L '/ int main /', / ^} /: main.c
Mostra como a função main () no arquivo main.c evoluiu ao longo do tempo.
log-3
Limita o número de confirmações a serem mostradas a 3.
DISCUSSÃO
O Git é, até certo ponto, agnóstico na codificação de caracteres.
· O conteúdo dos objetos blob são sequências de bytes não interpretadas. Não há
tradução de codificação no nível do núcleo.
· Os nomes de caminho são codificados no formato de normalização UTF-8 C. Isso se aplica a objetos de árvore,
o arquivo de índice, nomes de ref, bem como nomes de caminho em argumentos de linha de comando,
variáveis de ambiente e arquivos de configuração (.git / config (ver git-config(1)), gitignore(5)
gitatributes(5) e módulos git(5)).
Observe que o Git no nível do núcleo trata os nomes de caminho simplesmente como sequências de não NUL
bytes, não há conversões de codificação de nome de caminho (exceto no Mac e Windows).
Portanto, o uso de nomes de caminho não ASCII funcionará principalmente mesmo em plataformas e arquivos
sistemas que usam codificações ASCII estendidas legadas. No entanto, os repositórios criados em
tais sistemas não funcionarão corretamente em sistemas baseados em UTF-8 (por exemplo, Linux, Mac, Windows)
e vice versa. Além disso, muitas ferramentas baseadas em Git simplesmente assumem que os nomes de caminho são
UTF-8 e não exibirá outras codificações corretamente.
· As mensagens de log de confirmação são normalmente codificadas em UTF-8, mas outras codificações ASCII estendidas
também são suportados. Isso inclui ISO-8859-x, CP125x e muitos outros, mas não
Codificações multibyte UTF-16/32, EBCDIC e CJK (GBK, Shift-JIS, Big5, EUC-x, CP9xx
etc).
Embora encorajemos que as mensagens de log de confirmação sejam codificadas em UTF-8, tanto o núcleo quanto
Git Porcelain são projetados para não forçar UTF-8 em projetos. Se todos os participantes de um
projeto particular achar mais conveniente usar codificações legadas, Git não proíbe
isto. No entanto, há algumas coisas a serem lembradas.
1. git commit e git árvore de confirmação emite um aviso se a mensagem de log de confirmação fornecida a ele
não se parece com uma string UTF-8 válida, a menos que você diga explicitamente que seu projeto usa um
codificação legada. A maneira de dizer isso é ter i18n.commitencoding em .git / config
arquivo, assim:
[i18n]
codificação de confirmação = ISO-8859-1
Objetos de commit criados com a configuração acima registram o valor de i18n.commitencoding
em seu cabeçalho de codificação. Isso é para ajudar outras pessoas que olharão para eles mais tarde. Falta de
este cabeçalho implica que a mensagem de log de confirmação está codificada em UTF-8.
2. git log, git mostrar, git culpa e amigos olham para o cabeçalho de codificação de um commit
objeto e tente recodificar a mensagem de log em UTF-8, a menos que seja especificado de outra forma. Vocês
pode especificar a codificação de saída desejada com i18n.logoutputencoding em .git / config
arquivo, assim:
[i18n]
logooutputencoding = ISO-8859-1
Se você não tiver esta variável de configuração, o valor de i18n.commitencoding é
usado em seu lugar.
Observe que escolhemos deliberadamente não recodificar a mensagem de log do commit quando um commit é
feito para forçar UTF-8 no nível do objeto de confirmação, porque a recodificação para UTF-8 não é
necessariamente uma operação reversível.
CONFIGURAÇÃO
See git-config(1) para variáveis essenciais e git-diff(1) para configurações relacionadas ao diff
geração.
formato.bonito
Padrão para a opção --format. (Ver Bonita Formatos acima.) O padrão é médio.
i18n.logOutputEncoding
Codificação a ser usada ao exibir logs. (Ver Discussão acima.) O padrão é o valor de
i18n.commitEncoding se definido e UTF-8 caso contrário.
log.data
Formato padrão para datas legíveis por humanos. (Compare a opção --date.) O padrão é
"padrão", que significa escrever datas como Sáb, 8 de maio 19:35:34 2010 -0500.
log.seguir
Se verdadeiro, git log agirá como se a opção --follow fosse usada quando um único é
dado. Isto tem as mesmas limitações que --follow, ou seja, não pode ser usado para seguir
vários arquivos e não funciona bem no histórico não linear.
log.showRoot
Se for falso, o git log e os comandos relacionados não tratarão o commit inicial como um grande
evento de criação. Quaisquer commits de root na saída git log -p seriam mostrados sem um diff
em anexo. O padrão é verdadeiro.
mailmap. *
See git-shortlog(1).
notas.displayRef
Quais refs, além do padrão definido por core.notesRef ou GIT_NOTES_REF, ler
notas de quando mostrar mensagens de confirmação com a família de comandos de log. Ver git-
notas(1).
Pode ser um nome de ref não abreviado ou um glob e pode ser especificado várias vezes. UMA
aviso será emitido para refs que não existem, mas um glob que não corresponde a nenhum
refs é silenciosamente ignorado.
Esta configuração pode ser desabilitada pela opção --no-notes, substituída pelo
GIT_NOTES_DISPLAY_REF variável de ambiente e substituída por --notes =
opção.
GIT
Parte da git(1) suíte
Use git-log online usando serviços onworks.net
