Mantener los commits de reformateo fuera de git blame: -w y los archivos ignore-revs

Qué es

git blame anota cada línea con el commit que la modificó por última vez. Una ejecución de un formateador, un cambio de sangría o una normalización de finales de línea "cambian" todas las líneas, y a partir de entonces blame señala el commit de limpieza en lugar del cambio que introdujo la lógica. La documentación ofrece tres herramientas contra esto:

• -w ignora los espacios en blanco al comparar la versión del padre con la del hijo para decidir de dónde provienen las líneas.
• --ignore-rev <rev> trata un commit como si nunca hubiera ocurrido; las líneas que tocó se atribuyen al commit anterior que las modificó. --ignore-revs-file <file> lee esos commits desde un archivo, y blame.ignoreRevsFile en la configuración aplica un archivo automáticamente. Con blame.markIgnoredLines, las líneas reatribuidas se marcan con ?; con blame.markUnblamableLines, las líneas que no pueden atribuirse a ningún otro commit se marcan con *.
• -M detecta líneas movidas o copiadas dentro de un archivo, y -C detecta además líneas movidas o copiadas desde otros archivos modificados en el mismo commit, de modo que una refactorización que reubica código conserva la autoría original.

La documentación de GitHub indica que un archivo llamado .git-blame-ignore-revs en la raíz del repositorio se aplica automáticamente a su vista de blame.

Por qué importa

Blame es la forma en que quienes revisan, el personal de guardia y los agentes encuentran el razonamiento detrás de una línea: el mensaje del commit, la pull request, el ticket. Un historial en el que cada línea apunta a "apply black" o "prettier 3.0" pierde ese rastro justo en los momentos en que se necesita.

Cómo aplicarlo

• Mantener los cambios mecánicos grandes en commits propios, sin nada más en ellos, para poder ignorarlos en bloque.
• Añadir el hash completo de cada uno de esos commits a .git-blame-ignore-revs, con una línea de comentario que lo explique, y confirmar el archivo en el commit.
• Configurar git config blame.ignoreRevsFile .git-blame-ignore-revs en cada clon (mediante un script de configuración o un comando documentado); sin esto, la línea de comandos no aplica el archivo.
• Usar git blame -w -M -C como opción predeterminada al investigar, y -L <start>,<end> para limitar el rango.
• Los editores y los alojadores de código leen el mismo archivo; conviene comprobar cuáles lo hacen antes de depender de él.

Trampas

Ignorar un commit que también contenía cambios reales oculta esos cambios de blame. Los hashes deben estar sin abreviar (la documentación de configuración pide un nombre de objeto sin abreviar por línea), y tras una reescritura del historial los identificadores listados no coinciden con nada, por lo que el archivo debe regenerarse. git log -S y git bisect no se ven afectados y siguen encontrando el commit si es necesario.