¿Está bien que se hayan roto las confirmaciones intermedias, siempre que la confirmación final en cualquier tarea de empuje?

Depende en gran medida de la estrategia de bifurcación de su equipo, pero creo que tener compromisos fallidos en las ramas de desarrollo tiene mucho sentido en general: la gran "victoria" en el uso del control de código fuente es poder revertir pequeños cambios y a veces estás haciendo un montón de ellos y tienes que romper los huevos para hacer tortillas.

La forma sencilla de mantener las confirmaciones individuales sin contaminar el maestro es usar sucursales. Puedes poner las cosas de ruptura / experimentales allí para que puedas tener un historial detallado sin contaminar el historial de la rama maestra.

Los compromisos rotos son algo que "simplemente sucede", no debería significar el fin del mundo. Tengo una pequeña y molesta voz en la parte posterior de mi cabeza que me dice que uno no debería a sabiendas verificar el código roto, como una cuestión de principio y, por lo tanto, incluir versiones históricas, sin embargo, no es algo que yo Voy a la guerra por encima.

El muy alabado modelo de ramificación de Git hace que sea posible mantener compromisos rotos en sucursales específicas, por ejemplo. si su equipo adopta gitflow o una versión simplificada del mismo. Cualquier cosa con una política de "maestro limpio". En este caso, puede ingresar la versión final de trabajo como una confirmación de fusión, donde las versiones históricas (rotas) están disponibles en el repositorio pero fuera de la línea principal.

Si su equipo no ha adoptado un modelo de bifurcación, entonces tiene una excusa válida para simplemente empujar a todo el lote a dominar y terminar con él.

No, no está bien.

Si alguna vez hiciste un git bisect (y a quién no le gusta esa característica asesina), conoces el valor de un historial donde se construye cada compromiso.

Si tienes muchas confirmaciones durante un bisect que no se generan, tendrás muchas git bisect skip s que dificultan la búsqueda de la última confirmación buena.

Si terminas una rama de características y la combinas en el maestro, limpia la rama antes de fusionarla para que tu historial sea claro y esté en proceso de creación.

  

¿Alguien ha encontrado dificultades debido a fallos históricos comprometidos?   en maestro?

Sí. Backports, revertidos y bisectos son más difíciles. Así es leer la historia (ver más abajo).

  

Si es así, ¿existe una forma sencilla de evitar tales dificultades, sin descartar los mensajes y cambios de confirmación individuales?

No que yo sepa, aunque las sucursales son una solución decente.

Sin embargo, creo que descartar (o más bien aplastar) las confirmaciones individuales es lo correcto.

Durante el desarrollo, especialmente al hacer TDD, comprometerse temprano y con frecuencia es bueno. Desea tener el rastro completo de lo que está haciendo para poder retroceder, o averiguar exactamente cuándo las cosas empezaron a ir mal (o quizás se metió en una refactorización más grande de lo que puede masticar). Comprometerse.

Sin embargo, una vez que una característica / cambio está listo para ser empujado, un commit es un cambio empaquetado, idealmente atómico para que pueda ser revisado, rebasado, fusionado, seleccionado, revertido, visto en anotar] como independiente de otros cambios como sea posible.

Mirando la historia de un proyecto, un cambio de software se debe evaluar por sí solo. ¿Construye? ¿Viene con pruebas? ¿Funciona? ¿Qué hace? ¿Qué archivos necesitaban ser cambiados para entregar esa característica?

Tener que reunir compromisos, mientras sea posible (y ayudado por las combinaciones), lo hace más difícil. Por lo tanto, creo que limpiar tu historial antes de empujar es apropiado, incluso si eso significa perder el rastro de cómo llegaste a donde estás.

Respuesta corta: Sí

Pruebas:

El desarrollo basado en pruebas significa que escribes pruebas que se rompen (es decir, muestran un error).
Luego escribes el código para que las pruebas funcionen.

Desarrollo:

Comprometerse pequeño, Comprometerse a menudo.
Cada compromiso es un punto de retroceso. Si se da cuenta de que está en el camino equivocado, puede retroceder a un punto anterior con relativa facilidad. Si sus confirmaciones son lo suficientemente finas como para que pueda retroceder al punto correcto.

Advertencia:

Esto no significa

1) Verificas el código roto en el maestro.
2) Debes presionar todos los microcomités para que todos los revisen.

Usa ramas para hacer tu trabajo. Comprimir potencialmente las micro confirmaciones para los procesos de revisión para que estén en unidades lógicamente distintas con los comentarios apropiados. Si está utilizando git, no perderá el conjunto original de confirmaciones, solo puede crear un nuevo conjunto más lógico de confirmaciones para los procesos de revisión que se fusionarán en el maestro.

Creo que mientras los compromisos sean locales y no se envíen a otros, no solo está bien, sino que en realidad es una buena forma de trabajar. Simplemente no empuje el código roto a otros.