Posibles duplicados:
git / otro VCS: ¿con qué frecuencia se compromete?
¿Con qué frecuencia debo / cometo?
El uso del control de código fuente es muy diferente de un desarrollador a otro y de un proyecto a otro. Algunos cometen muy a menudo; otros pueden pasar un día entero o varios días sin comprometerse (especialmente cuando trabajan solo en el proyecto o saben que otros miembros del equipo están trabajando en una parte muy diferente del proyecto).
Ejemplos
A veces, he visto confirmaciones extremadamente pequeñas, tanto en la vida real como en transmisiones por Internet y otros materiales de aprendizaje. Algunos ejemplos, en su mayoría de la vida real, son:
-
Una confirmación que resuelve un error # ... o implementa una función # ... cambiando una línea de código.
En mi humilde opinión, es un caso perfectamente válido para un compromiso, especialmente si el sistema de seguimiento de errores está vinculado al control de versión y se actualiza automáticamente de acuerdo con las revisiones. Incluso sin este enlace, es útil rastrear qué compromiso resolvió qué, independientemente del número de cambios necesarios para resolver un error o implementar una función.
-
Una confirmación que cambia una configuración de configuración única (dado que en el contexto, las configuraciones de configuración deben estar en control de origen).
En mi humilde opinión, esto podría combinarse a veces con otro compromiso, a menos que la configuración anterior rompa la compilación o presente un error o pueda afectar a otros desarrolladores (por ejemplo, una cadena de conexión que cambió después de migrar el servidor de base de datos de prueba). >
-
Una confirmación que corrige la ortografía de una palabra, por ejemplo, en una cadena que se muestra al usuario.
En mi humilde opinión, en la mayoría de los casos, esto se puede combinar con otro commit (a menos que, de nuevo, se rompa la compilación). El único caso en el que no se puede combinar es cuando, si se deja, la ortografía incorrecta se puede propagar a través del código y sería demasiado complicada o imposible de cambiar más adelante, como en HTTP referer header .
-
Una confirmación que agrega un comentario a un método (mientras que el método ya era lo suficientemente explícito) o resuelve otra regla menor relacionada con el estilo.
Ejemplo: en .NET Framework, StyleCop requiere documentar todos los métodos, y el comentario XMLDoc para un constructor (que también es un método) debe comenzar con:
Inicializa una nueva instancia del < Nombre de clase aquí > clase.
Una confirmación puede aplicar esta última regla, reemplazando un comentario en el código heredado:
Crea un nuevo vehículo con el número especificado de ruedas.
por:
Inicializa una nueva instancia de la clase Vehículo, utilizando el número especificado de ruedas.
En otras palabras, la revisión no tiene otro significado que conformar la parte del código a los estándares de estilo utilizados en la base de código.
En mi humilde opinión, esto se puede combinar con otra confirmación en todos los casos (después de todo, las reglas relacionadas con el estilo deben ejecutarse en las confirmaciones para rechazar las confirmaciones del código que no coinciden con ellas), a menos que haya varios cambios en varios lugares.
Preguntas
¿Me equivoco en esos puntos?
¿Existe tal cosa como un compromiso demasiado pequeño, o es una práctica de cometer muy a menudo una buena práctica?
¿Merece la pena realizar cambios demasiado pequeños, dado que "contaminaría" el registro de revisión y haría más difícil encontrar los cambios relevantes entre pequeños cambios a los que nadie se preocupa y que no rompen o rompen la compilación, ¿No afectará a otros desarrolladores?