¿Es mejor fusionar "a menudo" o solo después de la finalización hacer una gran fusión de ramas de características?

Digamos que se están desarrollando múltiples ramas, Ay Btambién una rama incremental de "corrección de errores" C.

Ahora Cya está "terminado" y se fusionó con el maestro. Ay Btodavía están en desarrollo y no se solucionarán antes (tal vez) otra rama de corrección de errores se fusione con el maestro.

¿Es una buena idea fusionarse Clo antes posible en las nuevas ramas de funciones? ¿Para que las nuevas funciones se mantengan lo más cerca masterposible? ¿O es mejor dejar que la nueva característica se desarrolle en su propio "mundo" y que solo se fusione con el maestro una vez que haya terminado?

De todos modos, habrá conflictos, por lo que se debe dedicar tiempo a solucionarlos.

Cuanto más viva una rama, más puede desviarse de la rama principal y más confusa y complicada será la fusión resultante cuando finalmente esté terminada. Diez pequeños conflictos son más fáciles de resolver que un conflicto masivo, y en realidad pueden evitar que los desarrolladores dupliquen o desperdicien esfuerzos. Teniendo en cuenta que, usted debe combinar masteren Ay Bcon regularidad; una vez al día es una recomendación bastante común, aunque si tiene mucha actividad en sus sucursales, es posible que desee fusionarse varias veces al día.

Además de facilitar la resolución de conflictos, usted menciona específicamente Cuna rama de corrección de errores. Como desarrollador, me gustaría que mi sucursal tenga todas las últimas correcciones de errores, para garantizar que no repita el comportamiento que provocó un error o escriba pruebas basadas en datos erróneos.

De todos modos, habrá conflictos, por lo que se debe dedicar tiempo a solucionarlos.

Si sabe que habrá conflictos, es posible que desee adoptar una estrategia de ramificación diferente. Mantenga múltiples cambios en el mismo archivo (s) en la misma rama siempre que sea posible, y reducirá o eliminará la cantidad de conflictos. Refactorice las historias para que sean completamente independientes tanto como sea posible, y vuelva a trabajar las ramas para cubrir múltiples historias (la rama, la característica y la historia no siempre son intercambiables).

Asumiendo que su intención es fusionar A, B nuevamente en el maestro y mantener una sola base de código, nunca es una buena idea desviarse demasiado del maestro. Desviarse del maestro durante demasiado tiempo, especialmente cuando las correcciones de errores y otros desarrollos se fusionan para dominar a medida que se desarrollan A, B, ciertamente causarán conflictos.

Consideraría estrategias similares a las siguientes

1. Quien sea responsable de A, B debe observar de cerca al maestro y fusionarse en cualquier cambio.
2. Mejor aún, si tiene automatización de compilación y prueba, asegúrese de que A, B se fusionen en master y pasen las pruebas todas las noches.
3. Basándote en tu comentario a otra respuesta, parece que A, B podría tardar un tiempo en desarrollarse. En este caso, incluso puede considerar que A, B se fusionen entre sí para que, al final, no tenga mayores problemas para fusionar ambos en el maestro.
4. En un nivel superior, piense por qué necesita 2 líneas separadas de largo desarrollo. ¿Podría descomponerse en fusiones más pequeñas? ¿Podrías irrumpir en microservicios separados?

Por lo general, a menudo es mejor que uno masivo.

Las solicitudes de extracción más pequeñas y frecuentes son casi siempre mejores.

Empecé a usar indicadores de configuración principalmente para poder hacer solicitudes de extracción más tempranas para poder, a su vez, fusionar el código más fácilmente, pero dejar la función desactivada. Cuanto más pequeña sea la solicitud de extracción, más fácil será revisar el código, incluso si hay más solicitudes de extracción totales. La mayoría de los humanos de cualquier tipo no podrán realizar revisiones significativas de solicitudes de extracción masivas. Es demasiado difícil para la RAM mental de uno comprender todas las posibles implicaciones de un cambio masivo de código.

Hay una sobrecarga adicional al crear un indicador de configuración, por lo que no vale la pena en las características más pequeñas. Pero entonces su solicitud de extracción será pequeña de todos modos.

Sin embargo, puede haber situaciones en las que la función tenga que ser lanzada de una vez. Incluso entonces, podría ser mejor hacer solicitudes de extracción más pequeñas a otra sucursal hecha para ese propósito.

La mayoría de mis colegas se quejan cuando alguien crea una solicitud de extracción masiva, y en su mayor parte, con razón.

También tenga en cuenta que a veces necesito seleccionar los commits en ramas separadas. Si lo que necesita ser recogido de cereza se puede poner en un solo compromiso, hace que sea más fácil moverlo a otras ramas. Este es un caso en el que en realidad tener pocas confirmaciones es mejor, pero no es exactamente el proceso estándar si su cereza está buscando.

En Refactorización de Martin Fowler, el consejo que da es que nunca se debe ramificar una rama del maestro por más de un día. IIRC, debe hacer un pequeño cambio, probar para asegurarse de que no rompió nada, y luego fusionarlo nuevamente.

Otra opción para los cambios de larga duración que pueden estar terminados pero no listos para usar es colocarlos detrás de un indicador de función para que puedan fusionarse en el maestro pero no tengan riesgo de romper nada. Luego, cuando estén listos para usarse, se puede quitar el indicador de función.