¿Es una estrategia de fusión como Git Flow realmente un antipatrón?

Mi compañía está usando Git y está usando un esquema de ramificación peculiar: el trabajo se realiza en master y las ramas están reservadas para lanzamientos. Esto funciona bien, siempre que todo el trabajo realizado en una iteración llegue a la rama, pero si surge un problema de producción crítico, tenemos que asegurarnos de que el trabajo de alguna manera llegue a ambas ramas.

Últimamente, nos hemos estado divirtiendo con esas ramas. Ha sido un dolor de cabeza administrativo, garantizar que todo el trabajo llegue a cada rama, y algunos errores que se han corregido en una rama no lo convierten en maestro hasta que alguien lo señala, lo cual es preocupante.

Me encontré con Git Flow hace un tiempo, y siento que sería una solución a nuestro problema: el código no se filtra hasta el lanzamiento o hasta el final. El único inconveniente es que mi líder declaró que este tipo de desarrollo fue un antipatrón: se desarrolló furiosamente durante dos semanas y luego pasó tres para resolver los conflictos de fusión.

No estoy completamente seguro de estar de acuerdo, y desde que lo mencioné, el trabajo se ha reanudado normalmente. Solo recientemente hemos tenido algunos puntos importantes de dolor con esto.

Me gustaría saber: ¿por qué este tipo de esquema de desarrollo se considera un antipatrón? ¿ Es realmente un antipatrón?

— Makoto
fuente

La sección "Regla 3" de la antigua publicación de blog de Ted Dziuba podría ayudar a ilustrar cómo puede ser un antipatrón.

— Isxek

OMI, cuanto más tiempo real pases pensando en el control de versiones, más se ha ido mal con todo el usuario -> fenómeno de herramienta en primer lugar.

— Erik Reppen

@ErikReppen: Me gustaría alejar a todos del control de versiones y tener un proceso al que todos puedan acostumbrarse. De esta manera, no tenemos que preocuparnos por cosas como si esto es un antipatrón o no.

— Makoto

@Makoto Cualquier cosa que viole KISS es un anti-patrón, IMO. Aquí es donde los usuarios avanzados de VCS tienden a volverme loco.

— Erik Reppen

El término "antipatrón" es algo así como "mejor práctica", ya que a menudo sirve como una excusa para que las personas apaguen sus cerebros. No acepte esta noción si el líder no puede decirle claramente qué experiencia tiene con él y por qué es malo.

— Kyralessa

Respuestas:

Se refiere principalmente al lado de las ramas de características del modelo. Las ramas de características se declararon antipatrón hace mucho tiempo cuando las ramas duraron meses y los sistemas de control de versiones no pudieron fusionarse para salvarles la vida. Ramas de características que duran una semana o dos tienen mucho menos problemas, especialmente si usted está continuamente la fusión de develop en la rama función durante ese tiempo. Todavía no se recomienda nada mucho más que eso.

Incluso si no usa el lado de la rama de características del flujo de git, las otras partes son útiles para garantizar que obtenga fusiones limpias y sus cambios se propaguen en la dirección correcta.

— Karl Bielefeldt
fuente

Mi experiencia con las ramas de características, o la forma en que las hemos hecho, es que puede haber dolor de corazón con ellas si se les permite vivir por más de una iteración. Una regla que establezca que todas las características deben fusionarse en la iteración antes del lanzamiento sería agradable, para aliviar la angustia de las fusiones, y vaya, ¿hemos tenido una angustia grave detrás de esas ...

— Makoto

Mi experiencia es que puedes tener cosas locales por mucho tiempo, siempre y cuando las mantengas fusionadas con el maestro reciente o desarrolles según sea apropiado.

— Jan Hudec

@JaHudec ... o hasta que tenga dos cosas por ahí que sean conflictivas de alguna manera. Siempre debe tener una visión general de que se está haciendo ...

— johannes

Leyendo un poco, y la referencia de Martin Fowler parece indicar que las ramas de características realizadas en un flujo de integración continuo pueden funcionar, si se hacen en fragmentos más pequeños de lo que la mayoría de la gente consideraría hacer. Entonces, en cierto sentido, tiene razón: menos de dos semanas como tiempo de vida en una rama de características parece adecuado. Sin embargo, no veo cómo las ramas de características son el antipatrón.

— Makoto

Tienes razón. Solo son un antipatrón cuando viven demasiado tiempo sin fusionarse. A veces, las personas todavía se oponen a una idea cuando no recuerdan las razones subyacentes.

— Karl Bielefeldt

La fusión es algo gracioso: cuanto menos se haga, más difícil será, cuanto más difícil sea, más personas le temerán, con menos frecuencia lo harán.

La solución es no permitir que las ramas se desvíen demasiado o no usar ramas.

Si la gente entiende esto, probablemente no tendrá muchos problemas con la fusión, de lo contrario, puede que las sucursales no sean una buena idea sin cierta educación.

— maxim1000
fuente

No, no usar ramas no es un iniciador. El otro problema principal sería que el trabajo se puede hacer en dos lugares diferentes en el mismo código, por lo que esperamos que podamos hacer algo para aliviar eso también.

— Makoto

@makoto, a menudo desacoplar las cosas en el código hace los conflictos menos frecuentes. Puede ser la simple separación de una funcionalidad en funciones / clases o más de alto nivel evitando suposiciones no documentadas entre módulos. Entonces los cambios se vuelven más localizados.

— maxim1000

@ maxim1000 Estoy de acuerdo. Creo que alguien dijo una vez algo como "Un VCS es la alternativa de un hombre pobre a la arquitectura modular [desacoplada]"

— 8DH

+1 para el primer párrafo. Y sí, sin educación, gitflow-like es un callejón sin salida

— daitangio