Git
Português (Brasil) ▾ Topics ▾ Latest version ▾ git-blame last updated in 2.44.0

NOME

git-blame - Exiba qual revisão e qual foi o autor que alterou cada linha de um arquivo pela última vez

RESUMO

git blame [-c] [-b] [-l] [--root] [-t] [-f] [-n] [-s] [-e] [-p] [-w] [--incremental]
	    [-L <faixa>] [-S <revs-file>] [-M] [-C] [-C] [-C] [--since=<data>]
	    [--ignore-rev <rev>] [--ignore-revs-file <arquivo>]
	    [--color-lines] [--color-by-age] [--progress] [--abbrev=<n>]
	    [ --contents <arquivo> ] [<rev> | --reverse <rev>..<rev>] [--] <arquivo>

DESCRIÇÃO

Anota cada linha no arquivo informado com informações da revisão que modificou a linha pela última vez. Opcionalmente, comece a anotar a partir da revisão informada.

Quando informado uma ou mais vezes, a opção -L limita a anotação às linhas solicitadas.

A origem das linhas é seguida automaticamente pelas renomeações através de todos os arquivos (atualmente não há uma opção para desativar a presente renomeação). Para seguir as linhas movidas de um arquivo para outro ou para seguir as linhas que foram copiadas e coladas de um outro arquivo, etc., consulte as opções -C e -M.

O relatório não informa nada sobre quais as linhas foram eliminadas ou quais foram substituídas; é necessário utilizar uma ferramenta como "git diff" ou a interface "pickaxe" mencionada de forma breve no parágrafo seguinte.

Além de oferecer compatibilidade à anotação do arquivo, o Git também é compatível com a pesquisa no histórico do desenvolvimento para quando ocorra uma alteração num trecho do código. Isso torna possível o monitoramento quando um trecho do código for adicionado num arquivo, movido ou copiado entre os arquivos e eventualmente tenha sido excluído ou substituído. Funciona pesquisando uma sequência de texto no diff. Um pequeno exemplo da interface "pickaxe" que pesquisa por blame_usage:

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

OPÇÕES

-b

Mostra um SHA-1 vazio nos limites dos commits. Também é possível controlar através da opção de configuração blame.blankBoundary.

--root

Não trate os commits raiz com limites. Também é possível controlar através da opção de configuração blame.showRoot.

--show-stats

Inclui estatísticas adicionais no fim da saída do comando blame.

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

Anote apenas o intervalo das linhas informadas por <inicio>,<fim> ou pelo nome da função regex <nome-da-função>. Esta opção pode ser utilizada várias vezes. São permitidos intervalos sobrepostos.

<inicio> e <fim> são opcionais. -L <inicio> ou -L <inicio>, abrange do <inicio> para o final do arquivo. -L ,<fim> abrange do começo ao <fim>.

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

  • número

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

  • /regex/

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

  • +offset ou -offset

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

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

-l

Exibe o rev longo (Predefinição: desligado).

-t

Exibe o registro de data e hora em formato bruto (Predefinição: desligado).

-S <revs-file>

Utilize as revisões do arquivo-revs no lugar de chamar git-rev-list[1].

--reverse <rev>..<rev>

Avance com o histórico em vez de retroceder. Em vez de mostrar a revisão onde uma linha apareceu, isso mostra a última revisão onde uma linha existiu. Isso requer um intervalo de revisão como START…​END, onde o caminho para a falha exista em START. O comando git blame --reverse START é considerado como git blame --reverse START..HEAD por questão de conveniência.

--first-parent

Siga apenas o primeiro commit da origem ao ver um commit de mesclagem. Essa opção pode ser usada para determinar quando uma linha foi incorporado em um determinado ramo em vez da sua introdução no histórico geral.

-p
--porcelain

Exiba num formato designado para o consumo de uma máquina.

--line-porcelain

Exibe o formato porcelana, porém envie informações de cada linha do commit gerado e não apenas na primeira vez que um commit tiver uma referência. Implica no uso da opção --porcelain.

--incremental

Exiba o resultado incrementadamente num formado designado para o consumo de uma máquina.

--encoding=<codificação>

Defina a codificação a ser utilizada para gerar os nomes dos autores e do resumo dos commits. Definindo como none torna a saída "blame" em dados sem conversão. Para mais informações, consulte a discussão sobre codificação na página do manual git-log[1].

--contents <arquivo>

Anote usando o conteúdo do arquivo nomeado, iniciando em <rev> caso seja definido, caso contrário, HEAD. Você pode usar - para fazer o comando ler a partir da entrada padrão para dentro do arquivo.

--date <formato>

Especifica o formato utilizado para gerar as datas. Caso --date não seja utilizado, o valor da variável de configuração blame.date será utilizado. Caso a variável de configuração blame.date também não esteja definida, o formato ISO será utilizado. Para ver quais são os valores compatíveis, consulte a discussão da opção --date em git-log[1].

--[no-]progress

É predefinido que a condição do progresso seja relatado no fluxo de erros padrão quando estiver conectado num terminal. Essa flag permite que os relatórios de progresso sejam feitos ainda que não estejam conectados num terminal. Não é possível usar --progress junto com --porcelain ou --incremental.

-M[<num>]

Detecta se as linhas foram movidas ou copiadas dentro de um arquivo. Quando um commit move ou copia um bloco de linhas (o arquivo original tem A e depois B, e o commit o altera para B e depois A por exemplo), o algoritmo tradicional de blame (flaha) percebe apenas metade do movimento e normalmente aponta as linhas que foram movidas para cima (ou seja, B) para o commit principal e atribui a falha às linhas que foram movidas para baixo (ou seja, A) no commit relacionado. Com esta opção, os dois grupos de linhas são apontados no commit principal através da execução de passes extras durante a inspeção.

A opção <num> é opcional porém é o limite inferior da quantidade de caracteres alfanuméricos que o Git deve detectar como mover/copiar dentro de um arquivo para associar essas linhas ao commit de origem. 20 é o valor predefinido.

-C[<num>]

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

A opção <num> é opcional porém é o limite inferior da quantidade de caracteres alfanuméricos que o Git deve detectar como mover/copiar entre os arquivos para associar estas linhas ao commit de origem. 40 é o valor predefinido. Caso haja mais de uma opção -C, o argumento <num> do último -C entrará em vigor.

--ignore-rev <rev>

Ignora as alterações feitas pela revisão ao atribuir a blame (falha), como se a alteração nunca tivesse acontecido. As linhas que foram alteradas ou que foram adicionadas através de um commit que foi ignorado, serão atribuídos ao commit anterior que alterou esta linha ou as linhas próximas. Esta opção pode ser usada diversas vezes para ignorar mais de uma revisão. Se a opção de configuração blame.markIgnoredLines for definida, as linhas que foram alteradas por um commit ignorado e atribuídas a outro commit, serão marcadas com um ? ao serem gerados pelo blame. Se a opção de configuração blame.markUnblamableLines for definida, as linhas tocadas por um commit ignorado e que não pudemos atribuir a outra revisão, serão marcadas com um *.

--ignore-revs-file <arquivo>

Ignore as revisões listadas no arquivo, que deve estar no mesmo formato como em fsck.skipList. Essa opção pode ser repetida, e estes arquivos serão processados após quaisquer arquivos especificados com a opção de configuração blame.ignoreRevsFile. Um nome de arquivo vazio, "", limpará a lista das revisões dos arquivos que foram processados anteriormente.

--color-lines

Anotações das cores da linha no formato padrão, diferentemente se elas vierem do mesmo commit da linha anterior. Isso torna mais fácil distinguir os blocos de código introduzidos por diferentes commits. A cor predefinida é ciano e pode ser ajustada usando a opção color.blame.repeatedLines.

--color-by-age

Faça anotações coloridas na linha no formato padrão dependendo da idade da linha. A opção de configuração color.blame.highlightRecent controla qual cor é usada para cada faixa de idade.

-h

Exiba a mensagem de ajuda.

-c

Utilize o mesmo modo de saída como o git-annotate[1] (Predefinição: desligado).

--score-debug

Inclui informações de depuração relacionadas ao movimento das linhas entre os arquivos (consulte -C) e as linhas movidas dentro de um arquivo (consulte -M). O primeiro número listado é a pontuação. Esse é a quantidade de caracteres alfanuméricos detectados como tendo sido movidos entre os arquivos ou dentro deles. Isso deve estar acima de um determinado limite para que o git blame considere que estas linhas de código foram movidas.

-f
--show-name

Mostra o nome do arquivo no commit original. É predefinido que o nome do arquivo seja mostrado quando houver alguma linha proveniente de um arquivo com um nome diferente, devido à detecção de renomeação.

-n
--show-number

Exiba o número da linha no commit original (Predefinição: desligado).

-s

Suprima o nome do autor e o registro de data e hora da saída.

-e
--show-email

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

-w

Ignore os espaços durante a comparação da versão das origens e seus herdeiros para descobrir de onde vieram as linhas.

--abbrev=<n>

Em vez de usar os 7+1 dígitos hexadecimais predefinidos como o nome abreviado do objeto, use <m>+1 dígitos, onde <m> é pelo menos <n>, mas garante que os nomes dos objetos do commit sejam exclusivos. Observe que uma coluna é utilizada como um cursor para marcar o limite do commit.

O FORMATO PADRÃO

Quando nenhuma opção --porcelain nem --incremental for definida, a opção git blame produzirá uma anotação para cada linha com:

  • nome do objeto abreviado para o commit de onde a linha veio;

  • identidade do autor (por padrão, o nome do autor e a data, a menos que -s ou -e seja usado); e

  • número da linha

antes do conteúdo da linha.

O FORMATO PORCELANA

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

  • 40-byte SHA-1 do commit da linha é atribuído a;

  • o número da linha no arquivo original;

  • o número da linha no arquivo final;

  • Numa linha que inicia um grupo de linhas de um commit diferente do anterior, a quantidade de linhas neste grupo. Nas linhas subsequentes, este campo está ausente.

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

  • o nome do autor ("autor"), email ("autor-mail"), tempo ("author-time") e o fuso horário ("autor-tz"); da mesma forma para quem realizou o commit.

  • o nome do arquivo no commit ao qual a linha seja atribuída.

  • a primeira linha da mensagem do registro log do commit ("resumo").

O conteúdo da linha real são gerados após o cabeçalho acima, prefixado por um TAB. Permite adicionar mais elementos de cabeçalho posteriormente.

O formato porcelana geralmente suprime as informações de comprometimento que já foram vistas. Por exemplo, duas linhas que são atribuídas ao mesmo commit serão mostradas, mas, os detalhes deste commit serão mostrados apenas uma vez. Isso é mais eficiente, mas pode exigir que mais estados sejam mantidos pelo leitor. A opção --line-porcelain pode ser usada para gerar informações completas do commit para cada linha, permitindo um uso mais simples (porém, menos eficiente), como:

# conta a quantidade de linhas atribuídas para cada autor
git blame --line-porcelain file |
sed -n 's/^author //p' |
sort | uniq -c | sort -rn

DEFININDO OS INTERVALOS

Ao contrário do comando git blame e do git annotate nas versões mais antigas do git, a extensão da anotação pode ser limitada a intervalos de linhas e de revisão. A opção -L, que limita a anotação a um intervalo de linhas, pode ser utilizada várias vezes.

Quando quiser encontrar a origem para as linhas 40-60 do arquivo foo, utilize a opção -L assim (eles significam a mesma coisa - ambos pedem 21 linhas iniciando na linha 40):

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

Você tambem pode utilizar uma expressão regular para determinar o intervalo da linha:

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

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

Quando não quiser encontrar as alterações mais antigas que a versão v2.6.18 ou nas alterações anteriores a 3 semanas, utilize especificadores de intervalo da revisão similares ao git rev-list:

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

Quando os especificadores de intervalo da revisão forem utilizados para limitar a anotação, as linhas que não foram alteradas desde o limite do intervalo (seja o commit v2.6.18 ou o commit mais recente que seja 3 semanas mais antigo como no exemplo acima) são responsabilizadas por este limite do intervalo do commit.

Uma maneira particularmente útil é verificar se um arquivo adicionado tem linhas criadas a partir de copia e cola dos arquivos já existentes. Às vezes, isso indica que o desenvolvedor estava sendo desleixado e não refinou o código adequadamente. É possível encontrar o primeiro commit que introduziu o arquivo com:

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

e então anote a alteração entre o commit e as suas origens, utilizando a notação commit^!:

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

SAÍDA INCREMENTAL

Ao ser invocado com a opção --incremental, o comando gera o resultado à medida que vai sendo construído. Em geral, o resultado final falará primeiro sobre as linhas tocadas pelos commits mais recentes (ou seja, as linhas serão anotadas fora de ordem) e deve ser usado pelos visualizadores interativos.

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

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

    <40-byte-hex-sha1> <sourceline> <resultline> <quantidade-linhas>

    Os números das linhas começam a contagem a partir do 1.

  2. A primeira vez que um commit é exibido no fluxo, ele contém várias outras informações sobre ele impressas com uma tag de uma palavra no início de cada linha, descrevendo as informações adicionais do commit (autor, e-mail, quem fez o commit, as datas, resumo, etc.).

  3. Ao contrário do formato Porcelana, as informações do nome do arquivo são sempre informadas e encerram a entrada:

    "nome do arquivo" <citação-do-nome-do-arquivo-com-espaço-em-branco-vai-aqui>

    logo, é realmente muito fácil analisar alguma linha algo que seja orientado por palavra (que deve ser bastante natural para a maioria das linguagens de script).

    Note
    		 Para as pessoas que fazem a análise: visando a sua robustez, ignorare todas as linhas entre a primeira e a última (linhas "<sha1>" e "nome-do-arquivo") onde você não reconhece as palavras da etiqueta (ou particularmente não se importa com ela) no início das linhas de "informações estendidas". Dessa forma, caso haja alguma informação adicional (como a codificação do commit ou o comentário estendido do commit), o visualizador "blame" não se importará.

MAPEANDO AUTORES

Consulte gitmailmap[5].

CONFIGURAÇÃO

Warning

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

See original version for this content.
Warning

Missing pt_BR/config/blame.txt

See original version for this content.

VEJA TAMBÉM

git-annotate[1]

GIT

Parte do conjunto git[1]

scroll-to-top