¿Se pueden considerar las confirmaciones demasiado pequeñas? [duplicar]

14
  

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?

    
pregunta Arseni Mourzenko 23.02.2012 - 18:49
fuente

4 respuestas

31

Palabra equivocada es demasiado fuerte, porque es una cuestión de estilo / preferencia. Sin embargo, mi preferencia es aparentemente diametralmente opuesta a la tuya.

Prefiero ver las ediciones de estilo de codificación y los pequeños cambios de documentación realizados en sus propias confirmaciones. Si estoy haciendo una revisión del código, o tratando de averiguar dónde se introdujo un error, es mucho más fácil si cada confirmación no toca en media docena de problemas aleatorios. En mi mundo, un compromiso ideal corrige un error o completa una función. De esa manera, si la solución o la nueva característica tiene algún problema grave, retirarlo es mucho más fácil: no tiene que intentar desenredar una bolsa de cambios no relacionada con el problema.

Ahora, si tiene un lote de cambios que son solo problemas de documentación / formato, siéntase libre de agruparlos y su comentario de confirmación debe indicar "Solo cambios de formato / documentación".

    
respondido por el Charles E. Grant 23.02.2012 - 19:08
fuente
8

En primer lugar, no creo que haya una respuesta una a esta pregunta. Como señala, difiere mucho entre individuos y proyectos.

Aplico algo como la idea de SoC (Separación de Preocupaciones) a las confirmaciones. Es decir, trato de comprometerme "por tarea". O, en otras palabras, evite cometer "varias áreas de trabajo" a la vez. En ese sentido, no existe tal cosa como un compromiso demasiado pequeño.

    
respondido por el Magnus 23.02.2012 - 19:06
fuente
5

Las pequeñas confirmaciones son grandes. En mi humilde opinión, cuanto más pequeño, mejor. En particular, las pequeñas confirmaciones son buenas porque son fáciles de revisar. Preferiría revisar 5 pequeños cambios independientes que 1 cambio más grande que los incorpore a todos.

    
respondido por el Stephen Gross 23.02.2012 - 19:28
fuente
3

No creo que ningún compromiso sea demasiado pequeño siempre que el comentario sea correcto; la falta o la confusión de los comentarios de confirmación son reprensibles.

Personalmente prefiero confirmar cambios en grupos lógicos, por ejemplo, una confirmación para refactorizar antes de realizar cualquier cambio lógico, y luego otra para cambios para corregir el error.

También prefiero que los comentarios contengan algún detalle, así que revisaré todos los archivos que han cambiado para recopilar los cambios relacionados que pueden ser cubiertos por el mismo comentario, separando aquellos que necesitan algún detalle que no se aplique a otros archivos.

    
respondido por el Mike Partridge 23.02.2012 - 19:23
fuente

Lea otras preguntas en las etiquetas