¿Se debe realizar un cambio de código y el cambio correspondiente al conjunto de pruebas en una confirmación o dividir en dos? Considere el caso de una corrección de error que causa un pequeño cambio en la salida esperada, lo que obliga a un cambio menor en el conjunto de pruebas. Es extremadamente conveniente tener ambos cambios en la misma confirmación, ya que hace que sea obvio para el revisor exactamente qué se cambia en la salida. Por otro lado, a veces es posible que solo desee ver los diferenciales de la fuente, o los diferenciales de la salida esperada y es mucho más fácil hacerlo si las confirmaciones están separadas. Además, las dos cosas son lógicamente distintas, por lo que tiene sentido realizar confirmaciones distintas.

Me encantaría poder hacer dos commits distintos, pero de alguna manera tener los dos commits unidos de alguna manera (de modo que pueda seleccionar, revertir, etc. ambos commits como una unidad atómica). Además, si se realizan dos confirmaciones distintas, la suite de pruebas fallará en la primera confirmación (a menos que se introduzca una tercera confirmación para relajar la suite de pruebas), haciendo que las futuras bisecciones sean un dolor. El problema del fracaso futuro de los bisectos generalmente me alienta a realizar una única confirmación, pero las confirmaciones deben ser unidades lógicamente distintas y una confirmación al código es lógicamente distinta de una confirmación a la salida esperada en el conjunto de pruebas.

¿Hay alguna forma de hacer dos confirmaciones distintas y no tener que inclinarse hacia atrás para evitar que la bisección falle en una de ellas? (por ejemplo, tener que mencionar explícitamente las confirmaciones para omitir)