Cómo comentar un commit según Linus Torvalds
Cuando hablamos de hacer un commit en un sistema de control de versiones, no es más que subir los cambios que hemos hecho localmente a nuestro repositorio. Aunque cuando hablamos de repositorios descentralizados como el caso de Git, el repositorio de código también vive en nuestro sistema local, con la posibilidad de sincronizar con repositorios remotos.
Hecha una pequeña y vaga definición de la acción commit, decir también, que cuando subimos nuestros cambios al repositorio, tenemos la posibilidad de añadir un comentario explicando los cambios realizados. Esto, al ser una buena práctica, quizás sea el motivo por el cual Git, por defecto, no te deje hacer un commit sin introducir una explicación. Otros repositorios como Subversion por ejemplo, dicho comentario es opcional.
El problema de hacer que la explicación sea obligatoria, muchas veces hace que los programadores escriban cualquier tontería, como commit 1 2011-11-22, por ejemplo.
Supongo que Linus Torlvalds estará cansado de tener que revisar parches y actualizaciones para el kernel de Linux, que ha decidido publicar, lo que para él debe ser la estructura del comentario de un commit:
Línea cabecera: explica el commit en una línea
El cuerpo del mensaje del commit debería ser de varias líneas de texto, explicando con más detalle los cambios, incluso, describiendo el error corregido, etc.
El cuerpo del commit puede ser de varios párrafos y por favor corta las líneas de forma apropiada de forma que cada línea no exceda de 74 caracteres. De esta forma “git log” mostrará el texto de forma más amigable incluso cuando está identado.
Reported-by (Reportado por): la persona que lo reportó
Sing-off-by (persona que hizo el commit): tu nombre <tu email>
La cabecera, debería ser coherente y de sólo una línea. Ya que ésta es usada por herramientas como “gitk” y “shortlog” y debería de resumir el cambio en una sola línea, independiente de lo largo que sea el cuerpo del mensaje.
Aunque Linus hace clara referencia a una de sus criaturas, Git, esta práctica se podría (debería) aplicar a cualquier otro repositorio de control de versiones.
Buscar
Entradas Recientes
- Posts
- Reemplazando la bateria del AirTag
- OpenExpo Europe décima edición, 18 de mayo: El Epicentro de la Innovación y la Transformación Digital
- Docker Init
- Kubernetes para profesionales
- Agenda: OpenExpo Europe 2022 llega el 30 de junio en formato presencial
- Libro 'Manual de la Resilencia', de Alejandro Corletti, toda una referencia para la gestión de la seguridad en nuestros sistemas
- Mujeres hackers en ElevenPaths Radio
- Creando certificados X.509 caducados
- Generador de imágenes Docker para infosec