Setup and Config
Getting and Creating Projects
Basic Snapshotting
Branching and Merging
Sharing and Updating Projects
Inspection and Comparison
Patching
Debugging
External Systems
Server Admin
Guides
- gitattributes
- Command-line interface conventions
- Everyday Git
- Frequently Asked Questions (FAQ)
- Glossary
- Hooks
- gitignore
- gitmodules
- Revisions
- Submodules
- Tutorial
- Workflows
- All guides...
Administration
Plumbing Commands
- 2.43.0 11/20/23
- 2.42.1 no changes
- 2.42.0 08/21/23
- 2.41.0 06/01/23
- 2.40.1 no changes
- 2.40.0 03/12/23
- 2.39.1 → 2.39.3 no changes
- 2.39.0 12/12/22
- 2.38.1 → 2.38.5 no changes
- 2.38.0 10/02/22
- 2.37.1 → 2.37.7 no changes
- 2.37.0 06/27/22
- 2.36.1 → 2.36.6 no changes
- 2.36.0 04/18/22
- 2.35.1 → 2.35.8 no changes
- 2.35.0 01/24/22
- 2.33.3 → 2.34.8 no changes
- 2.33.2 03/23/22
- 2.33.1 10/12/21
- 2.33.0 08/16/21
- 2.32.1 → 2.32.7 no changes
- 2.32.0 06/06/21
- 2.31.1 → 2.31.8 no changes
- 2.31.0 03/15/21
- 2.30.1 → 2.30.9 no changes
- 2.30.0 12/27/20
- 2.29.1 → 2.29.3 no changes
- 2.29.0 10/19/20
- 2.27.1 → 2.28.1 no changes
- 2.27.0 06/01/20
RESUMO
git shortlog [<opções>] [<intervalo-das-revisões>] [[--] <caminho>…] git log --pretty=short | git shortlog [<opções>]
DESCRIÇÃO
Resume a saída git log em um formato adequado para inclusão nos anúncios de lançamento. Cada commit será agrupada por autor e título.
Além disso, o "[PATCH]" será retirado da descrição do commit.
Caso nenhuma revisão seja aprovada na linha de comando e a entrada padrão
não seja um terminal ou não houver uma ramificação atual, o git shortlog
exibirá um resumo do registro log lido da entrada padrão, sem referência ao
repositório atual.
OPÇÕES
- -n
- --numbered
-
Classifique a saída de acordo com a quantidade de commits feitas pelo autor, em vez da ordem alfabética do autor.
- -s
- --summary
-
Suprima a descrição do commit e forneça apenas um resumo da contagem dos commits.
- -e
-
Exibir o endereço de email de cada autor.
- --format[=<formato>]
-
Em vez do assunto do commit, utilize outras informações para descrever cada commit. O <formato> pode ser qualquer texto aceito pela opção
--format
do comando git log, assim como * [%h] %s. (Consulte a seção "FORMATOS BONITOS" do git-log[1].)Cada commit bem impresso será reorganizado antes de ser exibido.
- -c
- --committer
-
Colete e exiba as identidades de quem realizou os commits em vez dos autores.
- -w[<largura>[,<recuo1>[,<recuo2>]]]
-
Limite o tamanho das linhas geradas, quebrando a linha através da sua
largura
. A primeira linha de cada entrada é recuada pelos espaçosrecuo1
, assim como a segunda linha junto com as próximas, são recuadas pelos espaçosrecuo2
. Alargura
,recuo1
, erecuo2
estão predefinidos para 76, 6 e 9 caracteres, respectivamente.Caso a largura seja
0
(zero), recue as linhas da saída sem quebrá-las. - <intervalo da revisão>
-
Exibe apenas os commits no intervalo definido das revisões. Quando um <intervalo de revisão> não é definido, a predefinição retorna para
HEAD
(ou seja, todo o histórico que leva ao commit atual). Oorigin..HEAD
define todos os commits acessíveis a partir do commit atual (ou seja,HEAD
), porém não a partir doorigin
. Para uma lista mais completa das maneiras de escrever os nomes dos objetos, consulte a seção "DEFININDO AS REVISÕES" no gitrevisions[7]. - [--] <caminho>…
-
Considere apenas os commits que são suficientes para explicar como os arquivos que coincidam com determinados caminhos foram criados.
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,
limites --since=<date1>
para commits mais recentes que <data1>
, e usá-lo
com --grep=<padrão>
limita ainda mais para os commits cuja mensagem de
registro log possua uma linha que coincida com <padrão>
), a menos que
indicado de outra maneira.
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.
- --until=<data>
- --before=<data>
-
Exiba os commits mais antigos com data mais antiga das que foram informada.
- --author=<padrão>
- --committer=<padrão>
-
Limite os commits gerados para aqueles com linhas de cabeçalho do autor e de quem fez o commit que coincida com determinado padrão (expressão regular). Com um ou mais de um
--author=<padrão>
, são selecionados os commits cujo autor coincida com qualquer um dos padrões informados (é similar para vários--committer=<padrão>
). - --grep-reflog=<padrão>
-
Limite o commit gerado para aqueles com entradas de reflog que coincidam ao padrão informado (expressão regular). Com mais de uma opção
--grep-reflog
, são escolhidos os commits cuja mensagem do reflog coincida com qualquer um dos padrões informado. É um erro usar esta opção, a menos que o--walk-reflogs
esteja em uso. - --grep=<padrão>
-
Limite o commit gerado para aqueles com mensagem do registro log que coincida ao padrão informado (expressão regular). Com mais de uma opção
--grep=<padrão>
, os commits cuja mensagem coincida com qualquer um dos padrões informados (porém consulte--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 do 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
-
Exibe apenas os commits que tenham pelo menos (ou no máximo) aquela quantidade de pais dos commits. Em particular,
--max-parents=1
é o mesmo que--no-merges
,--min-parents=2
é o mesmo que--merges
. A opção--max-parents=0
informa todos os commits raiz e--min-parents=3
todas as mesclagens "polvo".As opções
--no-min-parents
e--no-max-parents
redefinem estes limites (para nenhum limite) novamente. As formas equivalentes são--min-parents=0
(qualquer commit que tenha 0 ou mais pais) e--max-parents=-1
(os números negativos indicam nenhum limite acima). - --first-parent
-
Siga apenas o primeiro commit da origem ao ver a mesclagem de um commit. Essa opção pode lhe fornecer uma melhor visão geral durante a visualização da evolução de um tópico específico no ramo, pois faz a mesclagem em um tópico no ramo e tende a ser apenas sobre o ajuste das atualizações upstream de tempos em tempos, esta opção permite ignorar os commits individuais trazidas para o seu histórico feitas por essa mesclagem. Não pode ser combinado com
--bisect
. - --not
-
Inverte o significado do prefixo {cursor} (ou falta dele) para todos os especificadores das revisões seguintes, até o próximo
--not
. - --all
-
Finja como se todos os refs em
refs/
junto comHEAD
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 ?, {asterisco}, ou [, /{asterisco} 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 ?, {asterisco}, ou [, /{asterisco} no final é implícito. - --remotes[=<padrão>]
-
Finja como se todos as refs no
refs/remotes
estejam listados na linha de comando como <commit>. Caso um <padrão> seja utilizado, limite as ramificações rastreadas remotamente que coincidam com aqueles da "shel glob" informada. Caso o padrão não tenha ?, {asterisco}, ou [, /{asterisco} no final é 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 ?, {asterisco}, ou [, /{asterisco} 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
, ourefs/remotes
quando aplicadas as opções--branches
,--tags
, ou--remotes
respectivamente, e devem começar comrefs/
quando for aplicado ao--glob
ou--all
. Se a intenção for um delimitador /{asterisco}, este deve ser utilizado de forma explicita. - --reflog
-
Finja que todos os objetos mencionados pelos
reflogs
estejam listados na linha de comando como<commit>
. - --alternate-refs
-
Finja como se todos os objetos mencionados como dicas "ref" dos repositórios alternativos fossem listados na linha de comando. Um repositório alternativo é qualquer repositório cujo diretório dos objetos seja definido no
objects/info/alternates
. O conjunto dos objetos incluídos podem ser modificados pelocore.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 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 refsrefs/bisect/good-*
na linha de comando. Não pode ser combinado com--first-parent
. - --stdin
-
Além dos <commits> listados na linha de comando, leia-os na entrada padrão. Caso um separador
--
seja visto, pare de ler os commits e comece a ler os caminhos para limitar o resultado. - --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
eB
, 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 (como por exemplo, “3º no b” pode ser a escolha seletiva do ramoA
). 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 deB
que estão emA
ou são equivalentes ao patch para um commit emA
. Em outras palavras, lista os commits com sinal+
dogit cherry A B
. Mais precisamente,--cherry-pick --right-only --no-merges
informa 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 comgit log --cherry upstream...meu-ramo
, semelhante aogit cherry upstream meu-ramo
. - -g
- --walk-reflogs
-
Em vez de percorrer a cadeia de ancestralidade do commit, passe pelas entradas do reflog vindo da mais recente para as mais antigas. Quando esta opção é utilizada, você não pode definir os commits para exclusão (ou seja, as notações ^commit, commit1..commit2 e commit1...commit2 não podem ser utilizadas).
Com o formato
--pretty
diferente dooneline
ereference
(por razões óbvias), isto faz com que a saída tenha duas linhas extras das informações extraídas do reflog. O designador reflog na saída pode ser exibido comoref@{Nth}
(ondeNth
é o índice cronológico reverso no reflog) ou comoref@{timestamp}
(com o registro de data e hora para esta entrada), dependendo de algumas regras:-
Caso o ponto inicial seja utilizado como
ref@{Nth}
, exiba o formato do índice. -
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
--data
foi utilizado na linha de comando, exibe o registro de data e hora no formato solicitado por--data
. -
Caso contrário, exibe o formato do índice.
Em
pretty=oneline
, a mensagem do commit é prefixada com estas informações na mesma linha. Esta opção não pode ser combinada com--reverse
. Consulte também git-reflog[1].Esta informação não será exibida de forma alguma sob
--pretty = reference
. -
- --merge
-
Após uma falha na mesclagem, exiba as refs que estão em atrito com os arquivos e não existam em todos os
HEADS
que serão mesclados. - --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 da história, como 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:
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
-
Quando um intervalo dos commits é exibido (como por exemplo, commit1..commit2 ou commit2 ^commit1), apenas exibe os commits que existem diretamente na cadeia de ancestralidade entre o commit1 e o commit1, ou seja, os commits que são ambos descendentes doe commit1 e os ancestrais do commit2.
Segue explicações com mais detalhes.
Suponha que você defina foo
como o <caminho>. Vamos chamar os commits que
alteraram foo
!TREESAME, e o restante TREESAME. (Em um diff filtrado
pelo 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 de simplificação. Assumimos que esteja
filtrando um arquivo foo
neste grafo do commit:
.-A---M---N---O---P---Q / / / / / / I B C D E Y \ / / / / / `-------------' X
A linha horizontal do histórico A---Q é considerada o primeira origem de cada mesclagem. Os commits são:
-
O
I
é o commit inicial ondefoo
existe com o conteúdo “asdf” e existe um arquivoquux
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”. -
O
B
contém a mesma alteração queA
. A mesclagemM
é trivial e portanto, TREESAME para todos os pais. -
O
C
não mudafoo
, mas a sua mesclagemN
o altera para “foobar”, portanto não é TREESAME para nenhum dos pais. -
D
definefoo
para “baz”. MesclaO
combinado com textos vindos de ` N` eD
a “foobarbaz”; ou seja, não é "TREESAME" para nenhuma das origens. -
O
E
alteraquux
para “xyzzy” e a sua mesclagemP
combina as sequências dos caracteres para “quux xyzzy”. OP
é TREESAME paraO
, porém não paraE
. -
O
X
é um commit raiz independente que adicionou um novo arquivoside
, eY
o alterou. OY
é TREESAME paraX
. MesclaQ
adicionouside
paraP
, eQ
e TREESAME paraP
, mas não paraY
.
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 serão incluídas caso não sejam TREESAME para nenhum dos parentes (embora isso possa ser alterado, consulte a opção
--sparse
abaixo). Se o commit foi uma mesclagem e também foi um TREESAME para um parente, siga apenas este parente. (Mesmo que haja vários parentes TREESAME, siga apenas um deles.) Caso contrário, siga todos.Isso resulta em:
.-A---N---O / / / I---------D
Observe como a regra para seguir apenas a origem TREESAME, caso haja um, removeu
B
completamente.C
foi considerado através doN
, mas é o TREESAME. Os commits raiz são comparadas com uma árvore vazia, entãoI
é !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 da predefinição em um ponto: sempre siga todos os pais de uma mesclagem, mesmo que seja TREESAME para um deles. Mesmo se mais de um lado da mesclagem tiver commits que estejam inclusos, isso não implica que a própria mesclagem seja! No exemplo, nós temos
I A B N D O P Q
O
M
foi excluído porque é TREESAME para ambos os pais.E
,C
eB
foram todos percorridos, porém apenasB
foi !TREESAME, para que os outros não apareçam.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 estão sempre inclusas. No entanto, sua lista de origens é reescrita: em cada origem, remova os commit que não foram inclusos. Isto resulta no
.-A---M---N---O---P---Q / / / / / I B / D / \ / / / / `-------------'
Compare com a opção
--full-history
sem reescrever acima. Observe queE
foi removido porque é um TREESAME, porém a lista dos parentesP
foi reescrita para conterE
parente doI
. O mesmo aconteceu paraC
eN
, eX
,Y
eQ
.
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çãoC'
no histórico final, de acordo com as seguintes regras:-
Defina
C'
paraC
. -
Substitua cada pai
P
doC'
por sua simplificaçãoP'
. No processo, solte os pais que são ancestrais dos outros pais ou que os commits raiz TREESAME em uma árvore vazia e remova as duplicatas, porém tome cuidado para nunca descartar todos os pais já que somos TREESAME também. -
Se após esta reescrita da origem, o
C'
for um commit raiz ou uma mesclagem (tem zero ou > origens), um commit limite ou !TREESAME, será mantido. Caso contrário, será substituído pela sua única origem.
O efeito disso é melhor mostrado através da comparação com a opção
--full-history
com a reescrita dos pais. O exemplo se transforma em:.-A---M---N---O / / / I B D \ / / `---------'
Observe que as maiores diferenças entre
N
,P
, eQ
sobre--full-history
:-
A lista dos pais de
N
teveI
removida, porque é um ancestral do outro paiM
. Ainda assim,N
permaneceu porque é !TREESAME. -
A lista de pais de
P
também removeu oI
. OP
foi então removido completamente, porque tinha um pai e é TREESAME. -
A lista de pais de
Q
tinha` Y` simplificado paraX
. OX
foi então removido, porque era uma raiz TREESAME. OQ
foi removido completamente, porque tinha um pai e é TREESAME.
-
Há um outra modo de simplificação disponível:
- --ancestry-path
-
Limite os commits exibidos àquelas diretamente na cadeia de ancestralidade entre os commits “from” e “to” no intervalo dos commits informados. Ou seja, exiba apenas os commits que são ancestrais do commit “to” (para) e os descendentes do commit “from”.
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 doD
. Isso é útil para ver o que aconteceu com a história que levou aM
desde oD
, no sentido que “o queM
possui e que não existia emD
”. O resultado neste exemplo seria todos os commits, excetoA
eB
(eD
, obviamente).Quando queremos descobrir o qual commit em
M
está contaminado com o bug introduzido porD
e precisa ser corrigido, contudo, podemos querer visualizar apenas o subconjunto D..M que são realmente descendentes doD
, como por exemplo, excluindoC
eK
. É exatamente isso que a opção--ancestry-path
faz. Aplicado à faixa D..M, resulta em:E-------F \ \ G---H---I---J \ 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 file.txt
que foi
modificado por A
, B
e` X` de maneiras diferentes. O único parente fa o
commit C
, Z
e Y
não alteram o file.txt
. O commit mesclado M
foi
criado resolvendo o conflito da mesclagem para incluir as alterações de A
e B
, portanto, também não é um TREESAME. O commit mesclado R
, no
entanto, foi criado ignorando o conteúdo do file.txt
no M
e levando
apenas o conteúdo de file.txt
no X
. Portanto, R
é o TREESAME para
X
, mas não para M
. Finalmente, a resolução de mesclagem natural para
criar N
é levar o conteúdo do file.txt
para R
, de modo onde N
seja
um TREESAME para R
, mas não para C
. O commit mesclado O
e P
são
TREESAME para seus primeiros parentes, mas não para seus os parentes
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 "trunk": as mesclagens não relacionadas ao manu
aparecem nos resultados do comando --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 pela 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 é:I---X---R---N
Aqui, a mesclagem do commit
R
eN
são incluídos porque obtiveram os commitsX
eR
para o ramo base, respectivamente. Essas mesclagens são a razão pela qual os commitsA
eB
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 deR
, o canto deN
paraM
foi simplificado. No entanto, oN
ainda aparece no histórico como um commit importante porque ele "obteve" as alterações vindas deR
para o ramo principal.
A opção --simplify-by-decoration
permite exibir apenas o quadro geral da
topologia do histórico, omitindo os commits que não sejam referenciadas
pelas tags. Os commits são marcadas como !TREESAME (em outras palavras,
mantidas após as regras da simplificação do histórico descritas acima) caso
(1) sejam referenciadas pelas tags ou (2) alteram o conteúdo dos caminhos
usados na linha de comando. Todos os outros commits são marcados como
TREESAME (assunto que será simplificado).
MAPEANDO AUTORES
O recurso .mailmap
é utilizado para agrupar os commits da mesma pessoa no
"shortlog", onde o seu nome ou endereço de email foram escritos de maneiras
diferentes.
Caso o arquivo .mailmap
exista no topo do repositório ou no local apontado
pelas opções da configuração mailmap.file
ou mailmap.blob
, ele será
utilizado para mapear os nomes dos autores e os endereços de email para os
seus respectivos nomes e endereços de email verdadeiros.
No formato simples, cada linha do arquivo consiste no nome real de um autor, espaço e um endereço de email utilizado no commit (delimitado por < and >) mapeando para o nome. Por exemplo:
Nome Próprio <commit@email.xx>
Os formatos mais complexos são:
<proper@email.xx> <commit@email.xx>
o que permite que o mailmap substitua apenas a parte do email de um commit e:
Nome Próprio <proper@email.xx> <commit@email.xx>
o que permite que o mailmap substitua ambos os nomes e o email de um commit correspondente ao endereço de email do commit especificado, e:
Nome Próprio <proper@email.xx> Nome de quem fez o Commit <commit@email.xx>
o que permite que o mailmap substitua ambos os nomes e o email de um commit que corresponda a ambos os nomes de quem fez o commit e com o endereço de email.
Exemplo 1: O seu histórico contém confirmações de dois autores, Jane e Joe, cujos nomes aparecem no repositório de diferentes maneiras:
Joe Developer <joe@example.com> Joe R. Developer <joe@example.com> Jane Doe <jane@example.com> Jane Doe <jane@laptop.(none)> Jane D. <jane@desktop.(none)>
Agora, suponha que Joe queira que seu nome do meio seja utilizado no começo
e Jane prefere que o nome de sua família seja escrito por extenso. Um
arquivo .mailmap
apropriado se pareceria com:
Jane Doe <jane@desktop.(none)> Joe R. Developer <joe@example.com>
Observe como não há necessidade de uma entrada para <jane@laptop.(none)>
porque o nome real deste autor já está correto.
Exemplo 2: O seu repositório contém commits dos seguintes autores:
nick1 <bugs@company.xx> nick2 <bugs@company.xx> nick2 <nick2@company.xx> santa <me@company.xx> claus <me@company.xx> CTO <cto@coompany.xx>
Então você pode querer um arquivo .mailmap
parecido com:
<cto@company.xx> <cto@coompany.xx> Some Dude <some@dude.xx> nick1 <bugs@company.xx> Other Author <other@author.xx> nick2 <bugs@company.xx> Other Author <other@author.xx> <nick2@company.xx> Santa Claus <santa.claus@northpole.xx> <me@company.xx>
Utilize o sinal de jogo da velha # para comentários que estejam em sua própria linha ou após o endereço de email.
GIT
Parte do conjunto git[1]