Los commits convencionales no salvarán tus mensajes de commit
Explora por qué simplemente seguir los commits convencionales no es suficiente para escribir buenos mensajes de commit, e introduce estrategias clave de pensamiento para mejorar tu proceso de desarrollo y crear naturalmente commits significativos.
YijunDeveloper
Deja de perder semanas en la autenticación de usuarios
Lanza aplicaciones seguras más rápido con Logto. Integra la autenticación de usuarios en minutos y concéntrate en tu producto principal.
Una búsqueda rápida en internet revelará una plétora de artículos que te enseñan cómo escribir mensajes de commit. El 90% de estos artículos te dicen que uses commits convencionales. Sin embargo, un número considerable de desarrolladores todavía lucha con esto. Saben que deben seguir estas convenciones, pero encuentran difícil aplicarlas en la práctica. Cada vez que hacen commit de código, agonizan sobre si escribir "refactorizar" o "tarea". Incluso he visto proyectos donde la lista de mensajes de commit consiste enteramente en el mismo mensaje: "feat: agregar página", porque escribir mensajes de commit fue demasiado desafiante para ellos, y simplemente se dieron por vencidos.
Es demasiado pronto para hablar de commits convencionales#
No estoy diciendo que los commits convencionales sean malos. Tienen muchos beneficios bien conocidos:
Proporcionan un formato unificado, haciendo que los mensajes de commit sean más estandarizados
Son fáciles de analizar para herramientas automatizadas, permitiendo la generación automática de changelogs
Ayudan a los miembros del equipo a comprender el propósito y alcance de los cambios de código
Permiten una identificación rápida de diferentes tipos de cambios de código
Sin embargo, cuando un desarrollador todavía lucha por escribir buenos mensajes de commit incluso después de usar commits convencionales, lanzarles un artículo sobre cómo usar commits convencionales, enseñándoles qué significa el tipo feat, qué significa el tipo fix, es en realidad sin sentido. Es como dar un libro de cocina avanzado a alguien que no sabe cocinar, sin enseñarle cómo usar ingredientes y utensilios básicos. Sin embargo, tales artículos están en todas partes en internet. Poco saben que los commits convencionales solo pueden ser verdaderamente efectivos cuando los desarrolladores tienen un pensamiento claro y la capacidad de dividir tareas con precisión.
Así que, los commits convencionales no son malos, pero antes de llegar a eso, necesitamos establecer la mentalidad de desarrollo correcta y usar el pensamiento de desarrollador científico para hacer las cosas.
Pensamiento clave para escribir buenos mensajes de commit#
Los cambios de código deben hacer una cosa a la vez#
En el desarrollo de software, "hacer una cosa a la vez" es un principio importante. Esto se aplica no solo a escribir código sino también a hacer commit del código. Cuando nos enfocamos en una tarea o cambio específico a la vez, nuestro código se vuelve más claro y nuestras intenciones más explícitas. Este método no solo mejora la legibilidad del código sino que también simplifica enormemente el proceso de revisión de código. Los revisores pueden entender y verificar más fácilmente el propósito de cada cambio.
Además, este método proporciona conveniencia para posibles reversiones de código. Si ocurren problemas, podemos ubicar y revertir cambios específicos más fácilmente sin afectar otras partes no relacionadas. Lo más importante, cuando cada cambio hace solo una cosa, el mensaje de commit que describe este cambio se vuelve naturalmente más preciso y significativo.
En práctica, esto significa que necesitamos definir claramente la tarea a completar antes de comenzar a codificar. Después de completar una tarea, deberíamos inmediatamente hacer commit del código, en lugar de esperar hasta que múltiples tareas se completen antes de hacer commit juntas. Si descubrimos otras áreas que necesitan modificación mientras completamos la tarea actual, el mejor enfoque es anotarlas y manejarlas por separado después de completar la tarea actual. Por ejemplo, cuando estás implementando una característica y descubres algunos errores existentes, lo que debes hacer no es arreglar el error de inmediato junto con tu nuevo código de característica, sino implementar primero la característica, luego arreglar el error que descubriste en otro commit, o arreglar el error primero y luego hacer commit de la característica.
Los mensajes de commit realmente existen antes de escribir código#
Muchos desarrolladores solo comienzan a pensar en cómo escribir mensajes de commit después de completar el código, pero en realidad, los mensajes de commit deben existir antes de empezar a codificar. Esto se debe a que los mensajes de commit esencialmente reflejan los pasos que tomamos para completar una tarea. En otras palabras, son nuestras tareas pendientes.
Cuando comenzamos una tarea, primero debemos pensar en qué pasos específicos se necesitan para completar esta tarea. Estos pasos son nuestra lista de tareas pendientes, y al mismo tiempo, son nuestros futuros mensajes de commit. Con esta lista de tareas, cada uno de nuestros cambios de código tiene un propósito, manteniéndonos enfocados mientras codificamos y evitando que nos desviemos de la tarea.
Más importante aún, este método puede mejorar significativamente nuestra eficiencia. Cuando completamos un paso, el mensaje de commit correspondiente ya está preparado, y podemos usarlo directamente, reduciendo el tiempo dedicado a pensar en cómo describir el cambio. Al mismo tiempo, debido a que estos mensajes de commit se completan cuando tenemos una comprensión integral de la tarea, suelen ser de mayor calidad y más informativos.
Supongamos que necesitas implementar una nueva característica de registro de usuario. Podrías planear los pasos de tu tarea así:
Refactorizar el componente de formulario existente para hacerlo más genérico y reutilizable
Crear un formulario de registro de usuario
Implementar la integración de API para el registro de usuario
Agregar pruebas unitarias para la característica de registro de usuario
Actualizar la documentación para la característica de registro de usuario
Los mensajes de commit correspondientes a estos pasos de tarea podrían ser los siguientes:
refactorizar: mejorar el componente de formulario existente para su reutilización
feat: crear formulario de registro de usuario
feat: implementar integración de API de registro de usuario
prueba: agregar pruebas unitarias para el registro de usuario
docs: actualizar la documentación para la característica de registro de usuario
De esta manera, tienes pasos de tarea claros y mensajes de commit concisos correspondientes antes de comenzar a codificar. Estos mensajes de commit son en realidad tu lista de tareas pendientes, guiándote a través de todo el proceso de implementación de la característica.
A medida que completas cada paso, puedes usar el mensaje de commit correspondiente para hacer commit de tu código. Esto no solo te ayuda a organizar mejor y ejecutar tareas, sino que también asegura que cada commit se enfoque en un paso específico, haciendo que todo el proceso de desarrollo sea más claro y manejable. Si necesitas ajustar ligeramente el mensaje de commit durante la codificación real, puedes hacer pequeñas modificaciones para describir más precisamente los cambios reales.
Los commits convencionales se convierten en una elección natural#
Cuando desarrollamos la mentalidad de desarrollo correcta, usar commits convencionales se convierte en algo natural. En este punto, encontrarás que elegir el prefijo de tipo apropiado (como feat, fix, refactor, etc.) se vuelve sin esfuerzo porque tus mensajes de commit ya reflejan claramente tus pasos de tarea.
Si deseas aprender más sobre cómo usar commits convencionales, hay muchos excelentes artículos disponibles en línea. Pero recuerda, estos estándares solo pueden ser verdaderamente efectivos cuando se construyen sobre la base de la mentalidad de desarrollo correcta.
Escribir buenos mensajes de commit no se trata solo de seguir un cierto formato. Requiere que mantengamos un pensamiento claro durante el proceso de desarrollo, aclaremos el propósito de cada cambio y consideremos cómo describir nuestro trabajo antes de comenzar a codificar.
Los commits convencionales son de hecho una herramienta útil, pero solo pueden ejercer su máximo efecto cuando se combinan con la mentalidad de desarrollo correcta. Al practicar los dos principios de "hacer una cosa a la vez" y "pensar en los mensajes de commit con anticipación", podemos no solo mejorar la calidad de los mensajes de commit sino también mejorar la eficiencia general del desarrollo y la calidad del código.
Espero que este artículo te ayude a replantearte tu proceso de desarrollo y te anime a probar estos métodos. Recuerda, los buenos hábitos de desarrollo toman tiempo en cultivarse, pero una vez formados, mejorarán enormemente tu eficiencia laboral y la calidad del código.
