Nunca he tenido la oportunidad de trabajar con un equipo en un repositorio, así que me pregunto si existe una forma adecuada de documentar los cambios.Repository Commit Msg Etiquette
Por ejemplo, ¿podría agregar una etiqueta (s) como: corrección de errores, actualizar, implementar? Solo curiosidad sobre cómo los profesionales describen sus compromisos.
Es de esperar que me va a ayudar a mantener el proyecto organizado ...
Debe ser una descripción clara y concisa de lo que fue cambiado o aplique de esa confirmación. Si se ha integrado con un sistema de seguimiento de problemas, el número del problema también es útil.
La conclusión es que el mensaje debe tener sentido para a) otras personas, para que entiendan lo que se hizo sin mirar el código, yb) usted mismo, cuando mira el registro un año después tratando de encontrar donde arreglaste el error con el foobar.
Ejemplo de un buen mensaje:
Fixed the bug where the program would crash if the number of entries was zero (issue #2857)
Ejemplo de un mal mensaje:
Fixed email bug
Hay muy diferentes enfoques para esto, algunas personas ni siquiera se utilizan los mensajes de confirmación, pero cometen un El archivo ChangeLog junto con el resto (no lo recomendaría, es difícil fusionarse todo el tiempo). Estoy de acuerdo con Michael en todo momento, solo quería señalar que los diferentes entornos son más o menos útiles a la hora de enviar mensajes, por ejemplo, git tiene un certain preference como deberían ser los mensajes.
Por ejemplo, si usa trac, le ayudará a poner el número de ticket allí con una cierta sintaxis (por ejemplo, # 1234, al menos creo que es), lo que hará que se muestre como un hipervínculo cuando se ve en la línea de tiempo de trac.
Tan prolija como sea posible es siempre la mejor idea.
También asegúrese de comentar ramas, etiquetas y combinaciones, correctamente. Le ahorrará dolores de cabeza.
es decir MERGE: [from location] [Start repo #] : [end repo #] - [additional comments]
Commit comentarios debería contener una breve descripción de lo que hizo y qué lo hizo, sin entrar en detalles sobre la forma: si alguien necesita este tipo de datos, que puede mirar el diffs. No complete los comentarios con detalles de implementación redundantes.