Para encontrar el commit que modificó por última vez una línea en un proyecto local de Git en tu Mac, abre Terminal, entra en el repositorio y ejecuta git blame en el archivo con el rango de números de línea. Luego, inspecciona ese commit con git show para leer su mensaje y su diff. Blame identifica el último cambio realizado en la línea actual; no siempre revela cuándo apareció por primera vez la línea ni por qué se escribió.

1. Abre el repositorio en Terminal

Si ya tienes el proyecto abierto en Finder, abre Terminal y escribe cd , luego arrastra la carpeta del proyecto a la ventana de Terminal y presiona Return. macOS insertará la ruta de la carpeta; esto evita escribirla mal. Como alternativa, escribe tú mismo la ruta y entrecomíllala si contiene espacios, por ejemplo:

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

Comprueba que estás dentro de un árbol de trabajo de Git y que Git está disponible:

git status --short
git --version

Si el primer comando indica que el directorio actual no es un repositorio Git, navega hasta el directorio del repositorio real del proyecto. Si git no está disponible, instala o habilita Git a través de una configuración de confianza antes de continuar. Los comandos a continuación utilizan la sintaxis estándar de shell y funcionan en el shell predeterminado de Terminal de macOS, así como en otros shells comunes.

2. Ejecuta blame para la línea que te interesa

Busca el número de línea en tu editor, luego sustituye la ruta del archivo y el número de línea a continuación. La ruta es relativa a la raíz del repositorio; entrecomíllala si contiene espacios o metacaracteres de shell.

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

-L 42,42 restringe la anotación a la línea 42. Git cuenta las líneas empezando desde 1. Para inspeccionar el contexto circundante, usa un rango como -L 38,46. Git muestra un identificador de commit, detalles del autor, información de la fecha y el texto de la línea. Su documentación describe blame como una herramienta que muestra la revisión y el autor que modificaron por última vez cada línea, y admite la selección de rangos de líneas con -L. Documentación de Git blame

Si no sabes el número de línea, abre el archivo en tu editor y utiliza los números de línea que muestra. También puedes aplicar blame a todo el archivo omitiendo -L:

git blame -- "Sources/Settings.swift"

Cuando no te encuentres en la raíz del repositorio, usa una ruta relativa al directorio donde ejecutaste el comando. Si Git indica que la ruta no existe, comprueba tanto tu directorio actual (pwd) como el uso exacto de mayúsculas y la ortografía de la ruta.

3. Lee el commit que identifica blame

Copia el identificador de commit que se muestra para la línea de destino y pásalo a git show:

git show --format=fuller --stat a1b2c3d

Reemplaza a1b2c3d por el identificador de tu salida. Esto muestra los metadatos del commit y un resumen de archivos. Para leer también el parche, omite --stat:

git show --format=fuller a1b2c3d

Observa las líneas modificadas alrededor de la línea de destino, el mensaje del commit y los demás archivos modificados en el mismo commit. Estos detalles pueden ayudar a explicar el contexto del cambio. El mensaje de un commit registra lo que escribió su autor; no es una prueba definitiva de las razones del diseño. Git documenta git show como una instrucción para mostrar información del commit y su diff textual. Documentación de Git show

Cuando blame apunta a un commit de formateo o traslado

Una línea puede haber sido afectada por una pasada de formato general, un cambio de nombre o un traslado de código. En ese caso, el commit señalado por blame puede no ser el que introdujo originalmente la lógica. Prueba la detección de traslados y copias:

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

-M le pide a Git que detecte líneas movidas dentro de un mismo archivo, mientras que -C también busca líneas copiadas o movidas desde otros archivos. Estas opciones ayudan a Git a rastrear algunas refactorizaciones, pero la detección depende de la coincidencia de contenido y es posible que no resuelva todos los historiales. Documentación de Git blame

Si un repositorio tiene un archivo .git-blame-ignore-revs para cambios amplios como formateo de código, puedes indicarle a Git que lo use:

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

Esto puede facilitar la localización del cambio relevante, pero las revisiones ignoradas afectan a la anotación; inspecciona el archivo de revisiones ignoradas del repositorio o compáralo con una ejecución de blame sin esa opción si el resultado parece sorprendente. La documentación de Git incluye esta opción, y GitHub documenta la misma convención de archivos para ignorar revisiones. Documentación de Git blame

Lo que blame no puede decirte

Blame anota líneas que existen en la versión de archivo seleccionada. No muestra directamente las líneas eliminadas o reemplazadas, y el commit modificador más reciente puede diferir del que la introdujo originalmente. Para ver texto eliminado o estados anteriores de un archivo, inspecciona los diffs y el historial de commits; la documentación de Git blame remite a git diff y a búsquedas en el historial para los cambios que eliminaron o reemplazaron contenido. Documentación de Git blame

Si el repositorio está alojado en GitHub y tienes acceso a él, también puedes abrir el archivo y seleccionar Blame para ver el historial línea por línea en el navegador. Haz clic en el mensaje de un commit para inspeccionar ese cambio, o usa el control de versiones para ver el archivo antes de él. GitHub Docs: Viewing and understanding files

Fuentes