git-blame - Online na nuvem

PROGRAMA:

NOME

git-blame - Mostra qual revisão e autor modificou pela última vez cada linha de um arquivo

SINOPSE

git culpa [-c] [-b] [-l] [--root] [-t] [-f] [-n] [-s] [-e] [-p] [-w] [--incremental]
[-EU ] [-S ] [-M] [-C] [-C] [-C] [--since = ]
[--abbrev = ] [ | --conteúdo | --reverter ] [-]

DESCRIÇÃO

Anota cada linha no arquivo fornecido com informações da revisão que durou
modificou a linha. Opcionalmente, comece a anotar a partir da revisão fornecida.

Quando especificado uma ou mais vezes, -L restringe a anotação às linhas solicitadas.

A origem das linhas é seguida automaticamente ao longo das renomeações de todo o arquivo (atualmente lá
não há opção para desativar o seguimento de renomeação). Para seguir as linhas movidas de um arquivo para
outro, ou para seguir linhas que foram copiadas e coladas de outro arquivo, etc., consulte o
Opções -C e -M.

O relatório não informa nada sobre as linhas que foram excluídas ou substituídas; tu
precisa usar uma ferramenta como git diff ou a interface "pickaxe" brevemente mencionada no
parágrafo seguinte.

Além de oferecer suporte à anotação de arquivo, o Git também oferece suporte à pesquisa no histórico de desenvolvimento
para quando um trecho de código ocorreu em uma mudança. Isso torna possível rastrear quando um código
snippet foi adicionado a um arquivo, movido ou copiado entre arquivos e, eventualmente, excluído ou
substituído. Ele funciona procurando por uma string de texto no diff. Um pequeno exemplo do
interface pickaxe que procura por blame_usage:

$ git log --pretty = oneline -S'blame_usage '
5040f17eba15504bad66b14a645bddd9b015ebb7 blame -S <ancestry-file>
ea4c7f9bf69e781dd0cd88d2bccb2bf5cc15c9a7 git-blame: Make the output

OPÇÕES

-b
Mostrar SHA-1 em branco para confirmações de limite. Isso também pode ser controlado por meio do
opção de configuração blame.blankboundary.

--raiz
Não trate os commits de root como limites. Isso também pode ser controlado por meio do
opção de configuração blame.showRoot.

--show-stats
Inclua estatísticas adicionais no final da produção de culpa.

-EU , , -EU :
Anote apenas o intervalo de linha fornecido. Pode ser especificado várias vezes. Sobreposição
intervalos são permitidos.

e são opcionais. "-EU ”Ou“ -L , ”Abrange de para
fim do arquivo. "-EU , ”Abrange desde o início do arquivo até .

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.

-l
Mostrar rotações longas (Padrão: desativado).

-t
Mostrar carimbo de data / hora bruto (Padrão: desativado).

-S
Use revisões de revs-file em vez de chamar lista de rev-git(1).

--marcha ré
Faça a história avançar em vez de retroceder. Em vez de mostrar a revisão em que um
linha apareceu, isso mostra a última revisão em que uma linha existiu. Isto exige
uma série de revisões como START..END, onde o caminho para culpar existe em START.

-p, --porcelana
Mostre em um formato projetado para o consumo da máquina.

--linha-porcelana
Mostra o formato de porcelana, mas envia informações de commit para cada linha, não apenas o
primeira vez que um commit é referenciado. Implica --porcelana.

- incremental
Mostre o resultado de forma incremental em um formato projetado para o consumo da máquina.

--encoding =
Especifica a codificação usada para enviar nomes de autores e resumos de confirmação. Configurando para
nenhum faz a culpa produzir dados não convertidos. Para obter mais informações, consulte a discussão
sobre a codificação no git-log(1) página de manual.

--conteúdo
Quando não é especificado, o comando anota as mudanças começando de trás para frente
a cópia da árvore de trabalho. Este sinalizador faz com que o comando pareça ser uma cópia da árvore de trabalho
tem o conteúdo do arquivo nomeado (especifique - para fazer o comando ler a partir do
entrada padrão).

--encontro
Especifica o formato usado para datas de saída. Se --date não for fornecido, o valor do
A variável de configuração blame.date é usada. Se a variável de configuração blame.date também não estiver definida,
o formato iso é usado. Para valores suportados, consulte a discussão sobre a opção --date
at git-log(1).

-M | |
Detecta linhas movidas ou copiadas em um arquivo. Quando um commit move ou copia um bloco de
linhas (por exemplo, o arquivo original tem A e B, e o commit muda para B e
então A), o tradicional culpa algoritmo percebe apenas metade do movimento e
normalmente culpa as linhas que foram movidas (ou seja, B) para os pais e atribui a culpa
para as linhas que foram movidas para baixo (ou seja, A) para o commit filho. Com esta opção, ambos
grupos de linhas são atribuídos ao pai por executar passagens extras de inspeção.

é opcional, mas é o limite inferior do número de caracteres alfanuméricos
que o Git deve detectar como se movendo / copiando dentro de um arquivo para associar essas linhas
com o commit pai. O valor padrão é 20.

-C | |
Além de -M, detecta linhas movidas ou copiadas de outros arquivos que foram modificados em
o mesmo commit. Isso é útil quando você reorganiza seu programa e move o código
entre arquivos. Quando esta opção é fornecida duas vezes, o comando procura adicionalmente
cópias de outros arquivos no commit que cria o arquivo. Quando esta opção é fornecida
três vezes, o comando adicionalmente procura por cópias de outros arquivos em qualquer confirmação.

é opcional, mas é o limite inferior do número de caracteres alfanuméricos
que o Git deve detectar como se movendo / copiando entre arquivos para associar essas linhas
com o commit pai. E o valor padrão é 40. Se houver mais de um -C
opções dadas, o argumento do último -C terá efeito.

-h
Mostrar mensagem de ajuda.

-c
Use o mesmo modo de saída que anotação do git(1) (Padrão: desligado).

--score-depurar
Inclui informações de depuração relacionadas ao movimento de linhas entre os arquivos (ver -C)
e linhas movidas dentro de um arquivo (consulte -M). O primeiro número listado é a pontuação. Isto é
o número de caracteres alfanuméricos detectados como tendo sido movidos entre ou dentro
arquivos. Isso deve estar acima de um certo limite para git culpa considerar essas linhas de
o código foi movido.

-f, --show-nome
Mostra o nome do arquivo no commit original. Por padrão, o nome do arquivo é mostrado se houver
qualquer linha que veio de um arquivo com um nome diferente, devido à detecção de renomeação.

-n, --show-número
Mostra o número da linha no commit original (Padrão: desligado).

-s
Suprima o nome do autor e o carimbo de data / hora da saída.

-e, --show-e-mail
Mostra o e-mail do autor em vez do nome do autor (Padrão: desativado). Isso também pode ser
controlado por meio da opção de configuração blame.showEmail.

-w
Ignore os espaços em branco ao comparar a versão do pai e a do filho para descobrir onde
as linhas vieram.

--abbrev =
Em vez de usar os dígitos hexadecimais padrão de 7 + 1 como o nome de objeto abreviado,
usar +1 dígitos. Observe que 1 coluna é usada para um acento circunflexo para marcar o commit de limite.

A PORCELANA FORMATO

Nesse formato, cada linha é produzida após um cabeçalho; o cabeçalho, no mínimo, tem o
primeira linha que tem:

· SHA-40 de 1 bytes do commit ao qual a linha é atribuída;

· O número da linha da linha no arquivo original;

· O número da linha da linha no arquivo final;

· Em uma linha que inicia um grupo de linhas de um commit diferente do anterior,
o número de linhas neste grupo. Nas linhas subsequentes, este campo está ausente.

Esta linha de cabeçalho é seguida pelas seguintes informações pelo menos uma vez para cada confirmação:

· O nome do autor ("autor"), e-mail ("autor-mail"), hora ("autor-hora") e fuso horário
("autor-tz"); da mesma forma para o committer.

· O nome do arquivo no commit ao qual a linha é atribuída.

· A primeira linha da mensagem de log de confirmação ("resumo").

O conteúdo da linha real é produzido após o cabeçalho acima, prefixado por um TAB. Esse
é permitir a adição de mais elementos de cabeçalho posteriormente.

O formato de porcelana geralmente suprime informações de commit que já foram vistas.
Por exemplo, duas linhas que são responsabilizadas pelo mesmo commit serão mostradas, mas o
os detalhes desse commit serão mostrados apenas uma vez. Isso é mais eficiente, mas pode exigir
mais estado seja mantido pelo leitor. A opção --line-porcelain pode ser usada para saída completa
confirme informações para cada linha, permitindo um uso mais simples (mas menos eficiente) como:

# conta o número de linhas atribuídas a cada autor
git blame --arquivo de porcelana em linha |
sed -n 's / ^ autor // p' |
classificar | uniq -c | sort -rn

ESPECIFICANDO GAMAS

Diferentemente dos git culpa e git anotada em versões mais antigas do git, a extensão da anotação
pode ser limitado a intervalos de linha e intervalos de revisão. A opção -L, que limita
anotação para um intervalo de linhas, pode ser especificada várias vezes.

Quando você estiver interessado em encontrar a origem das linhas 40-60 para o arquivo foo, você pode usar
a opção -L assim (eles significam a mesma coisa - ambos pedem 21 linhas começando na linha
40):

git culpa -L 40,60 foo
git blame -L 40, + 21 foo

Além disso, você pode usar uma expressão regular para especificar o intervalo de linha:

git blame -L '/ ^ sub hello {/, / ^} $ /' foo

que limita a anotação ao corpo da sub-rotina hello.

Quando você não está interessado em alterações anteriores à versão v2.6.18 ou alterações anteriores a 3
semanas, você pode usar especificadores de intervalo de revisão semelhantes a git lista de rev:

git blame v2.6.18 .. - foo
git blame --since = 3.weeks - foo

Quando especificadores de intervalo de revisão são usados ​​para limitar a anotação, linhas que não
mudou desde o limite do intervalo (o commit v2.6.18 ou o commit mais recente que
tem mais de 3 semanas no exemplo acima) são culpados por esse commit de limite de intervalo.

Uma maneira particularmente útil é ver se um arquivo adicionado tem linhas criadas por copiar e colar
de arquivos existentes. Às vezes, isso indica que o desenvolvedor estava sendo negligente e fez
não refatorar o código corretamente. Você pode primeiro encontrar o commit que introduziu o arquivo
com:

git log --diff-filter = A --pretty = short - foo

e então anote a mudança entre o commit e seus pais, usando commit ^! notação:

git blame -C -C -f $ commit ^! - foo

INCREMENTAL SAÍDA

Quando chamado com a opção --incremental, o comando exibe o resultado conforme é criado. o
saída geralmente falará sobre as linhas tocadas por commits mais recentes primeiro (ou seja, o
linhas serão anotadas fora de ordem) e deve ser usado por visualizadores interativos.

O formato de saída é semelhante ao formato de porcelana, mas não contém o formato real
linhas do arquivo que está sendo anotado.

1. Cada entrada de culpa sempre começa com uma linha de:

<Sha40 hexadecimal de 1 bytes>

Os números das linhas contam a partir de 1.

2. A primeira vez que um commit aparece no stream, ele contém várias outras informações
sobre isso impresso com uma etiqueta de uma palavra no início de cada linha que descreve o
informações de commit extra (autor, e-mail, committer, datas, resumo, etc.).

3. Ao contrário do formato de porcelana, a informação do nome do arquivo é sempre fornecida e termina
a entrada:

"nome do arquivo"

e, portanto, é realmente muito fácil de analisar para algum analisador orientado por linha e palavra
(o que deve ser bastante natural para a maioria das linguagens de script).

Note
Para quem faz análise: para torná-lo mais robusto, basta ignorar as linhas entre
o primeiro e o último (" linhas "e" nome do arquivo ") onde você não reconhece
as palavras da tag (ou se preocupe com aquela em particular) no início do
linhas de "informações estendidas". Dessa forma, se houver informações adicionadas (como
a codificação de commit ou o comentário de commit estendido), um visualizador de culpa não se importará.

MAPEAMENTO AUTORES

Se o arquivo .mailmap existe no nível superior do repositório, ou no local apontado
pelas opções de configuração mailmap.file ou mailmap.blob, é usado para mapear o autor e
nomes de committer e endereços de e-mail para nomes reais canônicos e endereços de e-mail.

Na forma simples, cada linha do arquivo consiste no nome real canônico de um
autor, espaço em branco e um endereço de e-mail usado no commit (entre < e >) mapear
para o nome. Por exemplo:

Nome própio[email protegido]>

As formas mais complexas são:

<[email protegido]>[email protegido]>

que permite que o mailmap substitua apenas a parte do e-mail de um commit e:

Nome própio[email protegido]>[email protegido]>

que permite que o mailmap substitua o nome e o e-mail de um commit correspondente ao
endereço de e-mail de confirmação especificado e:

Nome própio[email protegido]> Nome do compromisso[email protegido]>

que permite que o mailmap substitua o nome e o e-mail de um commit correspondendo aos
nome do commit e endereço de e-mail especificados.

Exemplo 1: Seu histórico contém confirmações de dois autores, Jane e Joe, cujos nomes aparecem
no repositório sob várias formas:

Joe Desenvolvedor[email protegido]>
Joe R. Desenvolvedor[email protegido]>
Jane Doe[email protegido]>
Jane Doe
Jane D.

Agora, suponha que Joe queira que a inicial do nome do meio seja usada e Jane prefira o sobrenome dela
totalmente explicado. Um arquivo .mailmap adequado seria semelhante a:

Jane Doe
Joe R. Desenvolvedor[email protegido]>

Observe como não há necessidade de uma entrada para , porque o nome real de
esse autor já está correto.

Exemplo 2: Seu repositório contém commits dos seguintes autores:

nick1[email protegido]>
nick2[email protegido]>
nick2[email protegido]>
papai noel[email protegido]>
claus[email protegido]>
CTO[email protegido]>

Então você pode querer um arquivo .mailmap parecido com:

<[email protegido]>[email protegido]>
Algum cara[email protegido]> nick1[email protegido]>
Outro Autor[email protegido]> nick2[email protegido]>
Outro Autor[email protegido]>[email protegido]>
Papai Noel[email protegido]>[email protegido]>

Usar hash # para comentários que estão em suas próprias linhas ou após o endereço de e-mail.

Use git-blame online usando serviços onworks.net