Las herramientas de control de versiones son lo suficientemente potentes como para permitir que la persona vea qué archivos se modificaron y qué métodos se agregaron. Significa que, en general, los mensajes de registro que duplican claramente lo que ya existe están contaminando el registro.
Agregó un somefuncmétodo 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 el contenido de una confirmación. El comentario debe describir el propósito de la confirmación.
fuente
No olvide agregar NÚMERO DE BOLETO / NÚMERO DE EMISIÓN .
Si tiene alguna función o sistema de seguimiento de problemas con un número de ticket o número de problema , asegúrese de incluir ese número de identificación en la confirmación. Eso ayudará a cualquiera que quiera saber más sobre la función o el problema en el que estaba trabajando.
En mi último proyecto, había una macro que se desarrolló para asegurar que los primeros 7 dígitos del comentario fueran un número de problema válido de la búsqueda clara (nuestro sistema de seguimiento de problemas / funciones).
fuente
Hago ese tipo de cosas cuando me comprometo, por ejemplo, la solución de un defecto que requiere cambios en varios archivos. Esto hace que sea un poco más fácil saber qué cambió realmente sin mirar los archivos individuales en el conjunto de cambios.
Para conjuntos de cambios de un solo archivo, esto es innecesario.
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.
fuente
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: "Actualizó build_foo () en fooutil.c para tomar un parámetro de barra".
fuente
Quiero agregar una perspectiva diferente aquí.
Mi respuesta es sí o no, pero generalmente diría que sí.
El control de versiones es lo suficientemente potente como para saber qué archivo se está actualizando. Pero cuando lo hacemos
Solo vemos el mensaje de confirmación. Eso es lo que hace la mayoría de la gente.
Al mirar en el registro en sí. Le agrega contexto adicional. Por ejemplo:
Es mejor que
Sin embargo, si los cambios generan múltiples archivos, al menos mencione el componente que se está editando.
Al leerlo, sabemos que el error que se está arreglando está en el componente API, y probablemente en el directorio API en la base del código.
Sin embargo, podríamos hacer
pero agrega más pasos solo para obtener los archivos.
fuente
El único momento en que podría ver que esto es ú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 el diff está abarrotado. Incluso entonces pondría el número de seguimiento de cambios # y una descripción de texto sin formato del cambio primero.
fuente
Creo que la verdadera pregunta aquí es cuán limitado en alcance son sus compromisos. Si espera para confirmar una variedad de cambios no relacionados juntos en una confirmación, es posible que sienta la necesidad de especificar qué archivos se cambiaron con qué propósito.
Sin embargo, si simplemente realizó confirmaciones más estrechas con mayor frecuencia, una única confirmación explicaría qué archivos se modificaron y simplemente podría describir cuál era el propósito del mensaje.
Más commits, más a menudo. Esa es la forma en que puede evitar ser tan detallado en sus mensajes.
fuente
No deberia
Todos los interesados pueden ver cambios en una historia
Tampoco es factible en sistemas más grandes, ya que muchos archivos pueden generarse automáticamente
fuente