Un historial que se pueda leer

Dentro de seis meses nadie se acordará de por qué esa condición tiene un + 1. Ni tú. El historial sí puede acordarse, pero solo si lo escribes pensando en la persona que lo va a leer, que probablemente seas tú a las once de la noche buscando un bug.

Un commit, un cambio#

Un commit debería poder revertirse él solo y dejar el proyecto en un estado coherente. Si al escribir el mensaje te sale un «y» («arregla el cálculo y actualiza el README»), es casi seguro que son dos commits.

# Añade por trozos en vez de por ficheros enteros
git add -p

git add -p es de esos comandos que cuesta un poco coger pero que luego no sueltas. Te va enseñando cada trozo modificado y le dices si entra o no.

El mensaje#

Corrige el cálculo de IVA en facturas prorrateadas

El importe se redondeaba antes de aplicar el prorrateo, lo que
desviaba el total un céntimo en periodos partidos.

Refs: #482

Lo que intento que se cumpla:

• La primera línea en imperativo y de menos de 72 caracteres, para que se lea entera en git log --oneline.
• El cuerpo cuenta por qué se hace el cambio, no qué se cambia. El qué ya está en el diff y no hace falta repetirlo.
• Una referencia al ticket o a la incidencia, si la hay.

Limpia la rama antes de publicarla#

Mientras la rama sea solo tuya, puedes reescribirla tanto como quieras. Y merece la pena hacerlo antes de abrir la pull request:

git rebase -i origin/main

Se abre el editor con una línea por commit, y en cada una eliges qué hacer:

Acción	Efecto
pick	Mantener el commit tal cual
reword	Mantenerlo y editar el mensaje
squash	Fundirlo con el anterior, combinando mensajes
fixup	Fundirlo con el anterior, descartando su mensaje
drop	Eliminarlo

Un truco que me ahorra mucho tiempo: cuando arreglas algo de un commit anterior, márcalo con --fixup y deja que Git lo coloque en su sitio solo.

git commit --fixup <sha-del-commit-original>
git rebase -i --autosquash origin/main

Sacarle partido al historial#

Todo esto tiene sentido porque luego el historial se lee. Estos son los comandos que más uso:

git log --oneline --graph --decorate   # la forma de las ramas
git log -p -- ruta/al/fichero          # cómo ha evolucionado un fichero
git log -S "nombreFuncion"             # cuándo apareció o desapareció un texto
git blame -w -C ruta/al/fichero        # quién escribió cada línea, ignorando reformateos

Si tengo que quedarme con uno, git log -S. Es la herramienta más infravalorada de Git: encuentra el commit exacto que introdujo una línea concreta, aunque desde entonces haya cambiado de fichero.