A dica Git da semana é sobre examinar quem fez o que dentro do Git.

A maioria dos sistemas de controle de versão tem o conceito de blame, mas no bom sentido. Isso permite que você veja quem fez alterações em um arquivo, ou quando o arquivo foi modificado pela última vez por alguém. O Git tem a mesma característica. Isso pode ser usado para descobrir que características foram adicionadas a um release em um processo conhecido como blamestorming.

Para descobrir quem alterou um arquivo, você pode executar git blame contra um único arquivo, e você terá um colapso do arquivo, linha por linha, com a mudança que afetou na última. Ele também imprime a informação de timestamp e de autor, bem como:

$ git blame file
566a0863 (Alex Blewitt 2011-07-12 09:43:39 +0100 1) First line
ed0a7c55 (Alex Blewitt 2011-07-12 09:43:51 +0100 2) Second line
8372b725 (Alex Blewitt 2011-07-12 09:44:06 +0100 3) Third line
ed0a7c55 (Alex Blewitt 2011-07-12 09:43:51 +0100 4)

Os timestamps e os hashes do commit abreviados mostram que as mudanças foram introduzidas sequencialmente, mas neste exemplo artificial é fácil de ver. Uma vez que o Git tem informações completas sobre o committer, ele pode mostrar o nome da pessoa ou o endereço de e-mail das pessoas:

$ git blame -e file
566a0863 ( 2011-07-12 09:43:39 +0100 1) First line
ed0a7c55 ( 2011-07-12 09:43:51 +0100 2) Second line
8372b725 ( 2011-07-12 09:44:06 +0100 3) Third line
ed0a7c55 ( 2011-07-12 09:43:51 +0100 4)

Às vezes, você obtém um ruído extra quando as diferenças de whitespace são introduzidas no arquivo. É possível usar -w para suprimir relatórios sobre mudanças que só afetam whitespace.

Há também mudanças que você pode mostrar em um subconjunto de faixas (como git diff, mas com linhas anotadas com o hash do commit). Por exemplo:

$ git blame ed0a..566a -- file
^566a086 (Alex Blewitt 2011-07-12 09:43:39 +0100 1) First line

Finalmente, se você tiver arquivos grandes, eles podem muitas vezes gerar mais saída do que o necessário. Você pode postar-filtrar os resultados, mas é mais eficiente dizer ao Git quais linhas você quer ver para que ele não precise fazer mais trabalho do que o necessário. Você pode especificar linhas com um número de linha explícita, (início/fim), um deslocamento da linha de partida (válido para o final apenas) ou uma expressão regular. Isso pode ser útil para usar o blame em uma função específica, se você está seguindo uma formatação parecida com C, onde a função começa na coluna zero. Isso nos permite ver detalhes de uma função específica (que inicia com ^bar) e para a próxima chave de fechamento (terminando com ^} depois do ^bar):

$ git blame tst.c
6bee4066 (Alex Blewitt 2011-07-12 09:57:54 +0100  1) foo() {
6bee4066 (Alex Blewitt 2011-07-12 09:57:54 +0100  2)    // the foo function
6bee4066 (Alex Blewitt 2011-07-12 09:57:54 +0100  3) }
6bee4066 (Alex Blewitt 2011-07-12 09:57:54 +0100  4) 
0cdc3645 (Alex Blewitt 2011-07-12 09:58:15 +0100  5) bar() { 
0cdc3645 (Alex Blewitt 2011-07-12 09:58:15 +0100  6)    // the bar function 
0cdc3645 (Alex Blewitt 2011-07-12 09:58:15 +0100  7) } 
6bee4066 (Alex Blewitt 2011-07-12 09:57:54 +0100  8) 
6bee4066 (Alex Blewitt 2011-07-12 09:57:54 +0100  9) main() {
6bee4066 (Alex Blewitt 2011-07-12 09:57:54 +0100 10)    // the main function
6bee4066 (Alex Blewitt 2011-07-12 09:57:54 +0100 11) }
$ git blame -L/^bar/,/^}/ tst.c
0cdc3645 (Alex Blewitt 2011-07-12 09:58:15 +0100 5) bar() { 
0cdc3645 (Alex Blewitt 2011-07-12 09:58:15 +0100 6)     // the bar function 
0cdc3645 (Alex Blewitt 2011-07-12 09:58:15 +0100 7) }

?

Texto original disponível em http://alblue.bandlem.com/2011/07/git-tip-of-week-assigning-blame.html