En la primera línea de un mensaje de confirmación de git, tengo la costumbre de mencionar el archivo que se modificó si un cambio no abarca varios archivos, por ejemplo:
Add [somefunc] to [somefile]
¿Es esto algo bueno o innecesario?
En la primera línea de un mensaje de confirmación de git, tengo la costumbre de mencionar el archivo que se modificó si un cambio no abarca varios archivos, por ejemplo:
Add [somefunc] to [somefile]
¿Es esto algo bueno o innecesario?
Las herramientas de control de versiones son lo suficientemente poderosas como para permitir que la persona vea qué archivos se modificaron y qué métodos se agregaron. Esto significa que, en general, los mensajes de registro que duplican claramente lo que ya existe están contaminando el registro.
Usted agregó el método somefunc para cumplir un requisito, es decir:
Esto significa que sus mensajes de registro deben explicar más bien qué características / errores se vieron afectados o cuál fue el propósito de la refactorización.
No. Hay muchas formas de examinar los contenidos de un compromiso. El comentario debe describir el propósito de la confirmación.
No olvide añadir TICKET / NÚMERO DE EDICIÓN .
Si tiene alguna función o un sistema de seguimiento de problemas con un número de ticket o número de problema , asegúrese de poner ese número de ID en la confirmación. Eso ayudará a cualquier persona que quiera saber más sobre la característica o el problema en el que estaba trabajando.
En mi último proyecto, había una macro que fue desarrollada para garantizar que los primeros 7 dígitos del comentario fuera un número de problema válido de Clear Quest (nuestro sistema de seguimiento de problemas / características).
Hago ese tipo de cosas cuando estoy cometiendo, por ejemplo. la solución para un defecto que requería cambios en varios archivos. Esto hace que sea un poco más fácil decir lo que realmente cambió sin mirar archivos individuales en el conjunto de cambios.
Para los conjuntos de cambios de un solo archivo, esto no es necesario.
La primera línea es siempre una descripción de alto nivel del conjunto de cambios, como un enlace al defecto o la historia del usuario.
Si es información relevante en la narrativa del mensaje de confirmación, entonces sí, inclúyala. Si el único bit de información es el nombre del archivo, entonces no.
Por ejemplo, esto tiene sentido: "Se movió la función build_foo () de fooutil.c a foobase.c, ya que la mayoría de los programas que desean usar build_foo () ya incluyen foobase.c"
Este no: "Se actualizó build_foo () en fooutil.c para tomar un parámetro de barra".
La única vez que pude ver que esto sea útil para un registro de un solo archivo es si ha realizado cambios en una función utilizada en muchos lugares dentro del archivo con el resultado de que la diferencia está desordenada. Incluso entonces pondría primero el número de seguimiento de cambios y una descripción de texto simple del cambio.
Creo que la pregunta real aquí es qué tan limitados son tus compromisos? Si espera cometer una variedad de cambios no relacionados juntos en una confirmación, entonces podría sentir la necesidad de especificar qué archivos se cambiaron con qué propósito.
Sin embargo, si simplemente realizas confirmaciones más estrechas con más frecuencia, entonces una sola confirmación explicaría qué archivos se modificaron y simplemente podrías describir cuál fue el propósito del mensaje.
Más confirmaciones, más a menudo. Esa es la forma en que puedes evitar ser tan detallado en tus mensajes.
No debería
Todos los interesados pueden ver los cambios en un historial
Tampoco es factible en sistemas más grandes, ya que muchos archivos pueden generarse automáticamente
Lea otras preguntas en las etiquetas git