¿Está bien tener compromisos intermedios rotos, siempre y cuando el compromiso final en cualquier inserción funcione?

Relacionado: ¿Debería cada git commit dejar el proyecto en un estado de trabajo?

Supongamos que hago los siguientes commits localmente:

• Modifique el esquema de la base de datos, rompiendo la aplicación.

• Actualice la aplicación para que sea compatible con el esquema de la base de datos nuevamente.

Mientras presione ambas confirmaciones, masterpermanece en un estado de trabajo. Sin embargo, una versión histórica está rota.

Soy consciente de que puedo usar git rebase -ipara aplastar los commits juntos. Sin embargo, la confirmación resultante será grande y menos descriptiva. Si necesito buscar en el historial de confirmaciones para averiguar por qué cambié algo, prefiero encontrar la confirmación original que muestre lo que hice y por qué.

Mis preguntas son:

• ¿Alguien ha encontrado dificultades debido a compromisos históricos rotos en el maestro?

• Si es así, ¿hay una manera simple de evitar tales dificultades, sin descartar los mensajes de confirmación individuales y los cambios?

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

La manera simple de mantener los commits individuales sin contaminar al maestro es usar ramas. Puede poner las cosas de última hora / experimentales allí para que pueda 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 voz molesta en la parte posterior de mi cabeza que me dice que uno no debería verificar a sabiendas el código roto, como una cuestión de principio y, por lo tanto, que incluye versiones históricas, sin embargo, no es algo por lo que iría a la guerra.

El modelo de ramificación muy elogiado de Git hace posible mantener los compromisos rotos fuera de las ramas específicas, por ejemplo, si su equipo adopta gitflow o una versión simplificada de los mismos. Cualquier cosa con una política de "maestro limpio". En este caso, puede verificar la versión final que funciona 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 ramificación de este tipo, entonces tiene una excusa válida para simplemente impulsar todo para dominarlo y terminar con eso.

No, no esta bien.

Si alguna vez hiciste una git bisect(y quién no ama esa característica asesina), sabes el valor de una historia donde se construye cada commit.

Si tiene muchas confirmaciones durante una bisectque no se construye, tendrá muchas git bisect skips que dificultarán encontrar la última buena confirmación.

Si finaliza una bifurcación de características y la fusiona en maestra, limpie la bifurcación antes de fusionarla para que su historial esté claro y en construcción.

¿Alguien ha encontrado dificultades debido a compromisos históricos rotos en el maestro?

Si. Backports, reversiones y bisectos son más difíciles. Así está leyendo la historia (ver más abajo).

Si es así, ¿hay una manera simple de evitar tales dificultades, sin descartar los mensajes de confirmación individuales y los cambios?

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

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

Durante el desarrollo, especialmente cuando se hace TDD, comprometerse temprano ya menudo es bueno. Desea el rastro completo de lo que está haciendo para poder retroceder o averiguar exactamente cuándo las cosas comenzaron a salir mal (o tal vez 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á lista para ser empujada, un commit es un cambio empaquetado, idealmente atómico para que pueda ser [revisado, rebase, fusionado, seleccionado, revertido, visto en anotaciones] tan independientemente de otros cambios como sea posible .

Mirando la historia de un proyecto, un cambio de software debe evaluarse por sí solo. ¿Se construye? ¿Viene con pruebas? ¿Funciona? ¿Qué hace? ¿Qué archivos se deben cambiar para ofrecer esa función?

Tener que armar commits, aunque sea posible (y ayudado por fusiones), lo hace más difícil. Por lo tanto, creo que limpiar tu historial antes de presionar es apropiado, incluso si eso significa perder la noción de cómo llegaste a donde estás.

Respuesta corta: sí

Pruebas:

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

Desarrollo:

Comprometerse pequeño, comprometerse a menudo.
Cada confirmación es un punto de reversión. Si se da cuenta de que está en el camino equivocado, puede retroceder a un punto anterior con relativa facilidad. Si sus commits son lo suficientemente finos, puede retroceder al punto correcto.

Consideración:

Esto no significa

1) Verifica el código roto en el maestro.
2) Debe impulsar todos los micro commits para que todos los revisen.

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

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