tag - qué tipos de etiquetas existen en git
Estándar a seguir cuando se escriben mensajes de confirmación de git (3)
Cuando acaba de describir lo que ha hecho (en términos técnicos aunque difusos como "función agregada"), no agrega mucho a lo que Git ya almacena en la confirmación. Imagínese leyendo el mensaje de compromiso algún tiempo después; ¿Qué tipo de resumen te ayudaría a recordar / comunicar a otros desarrolladores la esencia de ese cambio? Los contenidos exactos dependen de su proyecto y procesos, pero creo que es una buena guía.
Por lo tanto, antes que nada, agregue contexto (el por qué , no el cómo ) con su mensaje de confirmación (por ejemplo, "deje de utilizar el mensaje para habilitar la persistencia") en lugar de "función agregada de frob ()"). Es más esfuerzo (tienes que reflexionar y pensar ), pero vale mucho más.
Si desea explorar más sobre este tema, hay una gran cantidad de información, por ejemplo, este artículo de blog de Peter Hutterer o esta divertida diapositiva .
Esta pregunta ya tiene una respuesta aquí:
- Mensajes de Git Commit: 50/72 Formateo de 4 respuestas
Me encuentro administrando muchos archivos (más de 60 pero menos de 70) y mis mensajes de confirmación hasta ahora siguen este patrón: cuando agregué algo así como en layout.css , mi mensaje de confirmación es "algo agregado en el archivo layout.css" , y cuando elimino algo, mi mensaje de confirmación es "eliminado algo del archivo layout.css" .
Algunos archivos en el futuro, miro mi feed de commits y agregué ... y eliminé ... los mensajes dominan. A veces no recuerdo lo que layout.css o lo que agregué en layout.css ya que hago tantos cambios de una vez y me cuesta encontrar un mensaje de confirmación apropiado.
¿Hay algún estándar que deba seguir para ayudarme a elaborar mis mensajes de compromiso?
El modelo 50/72 parece ser una buena práctica. es decir ... la primera línea debe tener un máximo de 50 caracteres y debe servir como un encabezado. Seguido por un espacio, el segundo conjunto de línea debe estar envuelto en 72 caracteres y debe servir como un resumen. Aquí hay una pregunta SO: Mensajes de Git Commit: Formato 50/72 , que discute el mismo.
Aquí hay algunas notas exhaustivas sobre el tema:
Git ya sabe qué archivos ha modificado en una confirmación, es inútil especificarlo en el comentario. Simplemente diga, por ejemplo, "error de relleno fijo" o "menú agregado en la barra lateral". Deja en claro, eso es todo.