Editar: Dado que esta es, con mucho, mi respuesta más negativa, creo que vale la pena destacar lo que está oculto en el último párrafo: soy un propietario único. Tengo el 100% de la propiedad de estos proyectos y no trabajo con otros desarrolladores. En una tienda con más de un desarrollador, todo lo que digo en esta respuesta puede ser completamente inapropiado.
Me suscribo a DRY aquí como en todas las cosas.
Casi nunca agrego un comentario a mis confirmaciones. Un comentario casi siempre se repite. La respuesta a la pregunta "¿qué cambió en este compromiso?" casi siempre está en la diferencia.
Cuando miro un archivo y pregunto "¿qué diablos pasó aquí?", Lo primero que hago es mirar el diff con la versión anterior. El 90% de las veces la respuesta es inmediatamente aparente, ya sea porque el código es evidente por sí mismo o porque había algo no evidente que comenté en el código. Si no es así, correlaciono las fechas de rev del archivo con el sistema de seguimiento de errores y la respuesta está allí.
Esto siempre funciona. A veces se requiere una pequeña investigación para resolver algo, porque no comenté mi código adecuadamente. Pero nunca he podido encontrar la respuesta con bastante rapidez.
La única vez que agrego un comentario al registro de confirmación es cuando sé que un diff no me va a ayudar. Por ejemplo, cuando clasifico a los miembros de una clase: lo único que me dirá una diferencia en ese caso es que sucedió algo muy grande. Cuando lo hago, confirmo el archivo tan pronto como lo haya corregido. No hay un lugar apropiado para comentar un cambio de ese alcance en el archivo, por lo que agrego un comentario en el sentido de que el único cambio en esta revisión es reordenar a los miembros.
("¿Por qué no comentar un cambio como ese en el historial de revisión en la parte superior del archivo?", Podría preguntar. No guardo un historial de revisión en la parte superior de mis archivos. Dando miedo, cambiar el hábito de la vida de un cambio para hacer, y nunca me he arrepentido por un momento. El historial de revisión es Subversion.)
Si no tuve el 100% de la propiedad del proyecto, podría ser diferente. Puede ser muy difícil correlacionar las confirmaciones con correcciones de errores. Puede ser muy difícil capacitar a otros desarrolladores para codificar un estilo que permita confiar en el control de versiones de manera efectiva. Tendría que ver.
hacer su ambiente de trabajo para que pueda ir directamente desde el registro de entrada comentario al ticket. Una forma típica es hacer que se pueda hacer clic en el número del ticket. –