Commits atómicos

Separa los cambios no relacionados en commits distintos, de forma que cada commit sea una unidad lógica de trabajo. Este enfoque facilita entender el historial de cambios y revertirlos si hace falta.

Ventajas

• Más fáciles de entender: Los commits atómicos se centran en un único cambio lógico, así que otras personas (y tu yo del futuro) pueden entender mejor el propósito y el impacto de cada commit.
• Depuración más sencilla: Cuando aparece un bug, los commits atómicos facilitan localizar el commit exacto que lo causó, porque cada commit es un cambio autocontenido.
• Mejor colaboración: Los commits atómicos facilitan que el equipo revise cambios concretos y aporte comentarios sobre ellos, porque cada commit se centra en una sola tarea o corrección.
• Historial más limpio: Al mantener los commits atómicos, el historial del proyecto queda limpio y organizado, lo que facilita navegar por él y entender cómo ha evolucionado el código.
• Reversiones más fáciles: Si hace falta revertir un cambio concreto, los commits atómicos permiten hacerlo sin afectar a otros cambios no relacionados, reduciendo el riesgo de introducir problemas nuevos.
• Mejor cherry-picking: Los commits atómicos facilitan aplicar cambios concretos entre ramas con cherry-pick, porque cada commit representa una unidad de trabajo autocontenida.

Riesgos

Los commits atómicos pueden jugar en tu contra si te pasas:

• Granularidad excesiva: Dividir los cambios demasiado puede acabar en una cantidad exagerada de commits diminutos, difíciles de seguir y de razonar.
• Pérdida de contexto: Al centrarte en cambios pequeños y aislados, se puede perder la visión general y el contexto de la funcionalidad o corrección completa.
• Más carga de trabajo: Crear muchos commits pequeños exige dedicar más tiempo a crear commits, enviarlos y, quizá, abrir varias pull requests.
• Reversiones más difíciles: Si una funcionalidad necesita varios commits atómicos y hay que volver atrás, puede ser más difícil revertirla limpiamente.
• Menos legibilidad: La historia completa de un cambio puede quedar repartida en muchos commits, y eso hace más difícil que otros desarrolladores la entiendan leyendo el historial.

La clave está en encontrar el equilibrio: mantén los commits enfocados y fáciles de digerir, pero no tan granulares que pierdan sentido y se vuelvan difíciles de gestionar. El objetivo son commits lógicos y autocontenidos.