¿Por qué debería combinar código y testings en una única confirmación?

Digamos que escribo un cambio atómico de código. También escribo algunas testings para asegurarme de que el cambio funcione y siga funcionando.

Creo que debería confirmar el cambio de código junto con las testings.

PRO:

  • Esto asegura (en la medida de lo posible) que cada set de cambios de la bifurcación da como resultado la ejecución del código y la aprobación de testings.
  • Documenta que estas testings "pertenecen" al cambio de código que hice.

ESTAFA:

  • Es posible que desee retroceder el cambio sin retroceder en las testings en el futuro

¿Qué razones hay más para hacerlo de una manera u otra? Alguna estrategia te ha mordido alguna vez? ¿Cómo exactamente?

Algo relacionado: ¿Debería cambiarse el código por un compromiso separado del cambio correspondiente al set de testing?

Mi única regla es asegurarme de que el código se genere antes de registrarme.

Sí, lo ideal sería verificar los bits atómicos de código. Sin embargo, ¿cómo defines atómico? Y luego, ¿qué sucede si, más adelante, tienes que cambiar uno de los bits? Tus cambios ya no están en una confirmación.

Creo que debería confirmar el cambio de código junto con las testings.

Nunca lo hago, pero lo haría si utilizara un SCM no ramificado.

En la ramificación de SCM (he trabajado con mercurial y git) no es un problema.

Utilizo una twig diferente cada vez que comienzo a trabajar o algo así; Muchas veces tengo confirmaciones de sucursales locales que solo comprometen cambios pendientes (que ni siquiera se comstackn) cuando me desploop a otra cosa por un time, o cuando solo necesito un punto de respaldo antes de comenzar un cambio de código importante). Sé que la mayoría de esas confirmaciones intermedias nunca serán revisadas nuevamente, cuando las creo. Sin embargo, no afectan nada y son realmente útiles cuando es necesario.

Solo fusiono twigs cuando tengo código que comstack y testing que se ejecuta con éxito en él.