Para encontrar o commit que alterou pela última vez uma linha em um projeto Git local no seu Mac, abra o Terminal, navegue até o repositório e execute git blame no arquivo com o intervalo de linhas. Em seguida, inspecione esse commit com git show para ler a mensagem e o diff. O blame identifica a última alteração na linha atual; ele nem sempre revela quando a linha apareceu pela primeira vez ou por que foi escrita.

1. Abra o repositório no Terminal

Se você já estiver com o projeto aberto no Finder, abra o Terminal e digite cd , depois arraste a pasta do projeto para a janela do Terminal e pressione Return. O macOS inserirá o caminho da pasta; isso evita erros de digitação. Como alternativa, insira o caminho você mesmo e coloque-o entre aspas se contiver espaços, por exemplo:

cd "/Users/sam/Projects/My App"

Verifique se você está dentro de uma árvore de trabalho do Git e se o Git está disponível:

git status --short
git --version

Se o primeiro comando informar que o diretório atual não é um repositório Git, navegue até o diretório real do repositório do projeto. Se o git não estiver disponível, instale ou ative o Git por meio de uma configuração confiável antes de continuar. Os comandos abaixo usam a sintaxe padrão do shell e funcionam tanto no shell padrão do Terminal do macOS quanto em outros shells comuns.

2. Execute o blame para a linha desejada

Encontre o número da linha no seu editor e, em seguida, substitua o caminho do arquivo e o número da linha abaixo. O caminho é relativo à raiz do repositório; coloque-o entre aspas se contiver espaços ou metacaracteres de shell.

git blame -L 42,42 -- "Sources/Settings.swift"

-L 42,42 restringe a anotação à linha 42. O Git conta as linhas a partir de 1. Para inspecionar o contexto ao redor, use um intervalo como -L 38,46. O Git exibirá o identificador do commit, detalhes do autor, informações de data e o texto da linha. A documentação descreve o blame como uma ferramenta que mostra a revisão e o autor que modificaram cada linha pela última vez, oferecendo suporte à seleção de intervalos de linhas com -L. Documentação do Git blame

Se você não souber o número da linha, abra o arquivo no seu editor e use os números de linha exibidos nele. Você também pode aplicar o blame ao arquivo inteiro omitindo o -L:

git blame -- "Sources/Settings.swift"

Quando você não estiver na raiz do repositório, use um caminho relativo ao diretório onde executou o comando. Se o Git informar que o caminho não existe, verifique tanto o diretório atual (pwd) quanto o uso exato de maiúsculas/minúsculas e a grafia do caminho.

3. Leia o commit identificado pelo blame

Copie o identificador de commit exibido para a linha de destino e passe-o para o git show:

git show --format=fuller --stat a1b2c3d

Substitua a1b2c3d pelo identificador da sua saída. Isso exibe os metadados do commit e um resumo dos arquivos. Para ler o patch também, omita --stat:

git show --format=fuller a1b2c3d

Observe as linhas alteradas ao redor da linha de destino, a mensagem de commit e os outros arquivos modificados no mesmo commit. Esses detalhes podem ajudar a explicar o contexto da alteração. Uma mensagem de commit registra o que o autor escreveu; ela não é uma prova irrefutável da lógica do projeto. A documentação do Git descreve o git show como um comando para exibir informações do commit e seu diff textual. Documentação do Git show

Quando o blame aponta para um commit de formatação ou movimentação

Uma linha pode ter sido afetada por uma formatação ampla, renomeação ou movimentação de código. Nesse caso, o commit apontado pelo blame pode não ser o que introduziu a lógica originalmente. Tente usar a detecção de movimentação e cópia:

git blame -M -C -L 42,42 -- "Sources/Settings.swift"

-M solicita que o Git detecte linhas movidas dentro do mesmo arquivo, enquanto -C também procura linhas copiadas ou movidas de outros arquivos. Essas opções ajudam o Git a rastrear algumas refatorações, mas a detecção depende da correspondência de conteúdo e pode não resolver todos os históricos. Documentação do Git blame

Se um repositório tiver um arquivo .git-blame-ignore-revs para alterações amplas, como formatação, você pode instruir o Git a usá-lo:

git blame --ignore-revs-file .git-blame-ignore-revs -L 42,42 -- "Sources/Settings.swift"

Isso pode facilitar a localização da alteração relevante, mas revisões ignoradas afetam a anotação; inspecione o arquivo de ignorados do repositório ou compare com uma execução do blame sem essa opção se o resultado parecer inesperado. A documentação do Git lista essa opção, e o GitHub documenta a mesma convenção para arquivos de revisões ignoradas. Documentação do Git blame

O que o blame não pode lhe dizer

O blame anota linhas que existem na versão selecionada do arquivo. Ele não mostra diretamente linhas excluídas ou substituídas, e o commit modificador mais recente pode diferir da introdução original. Para textos excluídos ou estados anteriores do arquivo, inspecione os diffs e o histórico de commits; a documentação do blame do Git recomenda o uso de git diff e buscas no histórico para alterações que removeram ou substituíram conteúdo. Documentação do Git blame

Se o repositório estiver hospedado no GitHub e você tiver acesso a ele, também poderá abrir o arquivo e selecionar Blame para ver o histórico linha por linha no navegador. Clique em uma mensagem de commit para inspecionar essa alteração ou use o controle de versões para visualizar o arquivo como ele era antes dela. GitHub Docs: Viewing and understanding files

Fontes