¿Aún se considera (o se considera) que la ramificación de funciones es una mala práctica?

Viniendo del mundo de TFS y acabando de sentirme lo suficientemente cómodo con Git, estoy a punto de proponerle a mi equipo que debemos incorporar el flujo de trabajo de Gitflow como lo señala el famoso artículo de Vincent Dressen en el futuro.

Casi toda la literatura actual sobre estrategias de ramificación expresa la efectividad del flujo de trabajo de Gitflow, que es una versión extendida de la ramificación de características, pero los artículos datedos de ingenieros influyentes, como el artículo de Martin Fowler Branch Branch (2009) , desprestigian la ramificación en general en favor de la continuous integration.

Algunos de sus críticos declararon que la oposition de Fowler a la bifurcación de funciones era en parte porque usaba SVN como su VCS, que era una herramienta ineficaz para la fusión y por lo tanto llevó a Fowler a recomendar una "paranoia de fusión" antipatrón.

Fowler luego respondió en 2011 diciendo que los sistemas DVCS pueden facilitar la fusión, pero aún no resuelven los conflictos semánticos . Ahora en 2014, contamos con herramientas de fusión con reconocimiento de idiomas, como Semantic Merge , que podría resolver este problema por completo.

Mis preguntas son

  1. ¿La ramificación de funciones y la continuous integration son mutuamente exclusivas?

  2. ¿Qué tan relevante es el artículo de Fowler en el desarrollo moderno, especialmente con nuestra accesibilidad a herramientas como SourceTree, Git, Jenkins y otro software de revisión de código que hace que la creación de funciones y cosas similares sea mucho más fácil?

Según mi experiencia, depende de dónde se crean las twigs de características. Si está siguiendo un tenedor y un model de combinación, donde las twigs de function se crean en el tenedor, entonces no veo ningún problema. Desde el punto de vista del proyecto principal, sigue siendo solo una twig (principal); el único lugar donde aparecen las twigs de características está en su fork, y la única razón para usarlas es aislar los cambios que está enviando (en forma de request de extracción) contra la twig principal.

Si nos fijamos en el artículo de Wikipedia sobre continuous integration (hoy), verá que se trata de fusionarse con una sola línea principal a diario. Basado en eso, diría que la respuesta a su pregunta número uno es afirmativa, pero eso no excluye el uso de una estrategia de ramificación de características.

Para su pregunta, número dos, no creo que la respuesta sea tan directa, pero en mi experiencia, crear twigs es fácil, y fusionarlas después de la entropía no lo es. Todavía encuentro que el artículo de Fowler es exacto.

  1. No, puede configurar CI en ambas líneas principales y cada twig de funciones no hay problema.

  2. Todavía es muy relevante. Aunque los algorithms de fusión automatizados son cada vez mejores, incluida la combinación basada en la semántica, aún es imposible que una computadora infiera un significado. Hasta que tengamos verdadera inteligencia informática, esto seguirá siendo un problema. La pregunta es, ¿cuál es el% de los casos en que la fusión automática produce un resultado incorrecto y cuál es el% de los casos donde sabe que produciría un resultado incorrecto. Básicamente, si pudieras deducir automáticamente todos los casos en los que fallaría la fusión automática, podrías enrutarlos a humanos. Pero ese es también un problema difícil de resolver. El peor de los casos no es cuando la fusión automática no puede fusionar el código, sino cuando puede fusionarlo, pero lo combina incorrectamente, generalmente en semántica o como resultado de una condición de carrera o algún otro problema que no se identifica fácilmente sin una visión humana.

En general, las twigs de características son muy útiles para aislar los cambios en un equipo pequeño que trabaja en una function donde no está seguro de su calidad, el código podría afectar negativamente a otros equipos más grandes que trabajan en el proyecto o no está seguro si la característica en la próxima versión.

Desea limitar el uso de twigs de características al mínimo time posible. Fusionar código entre dos twigs con sets complejos de cambios podría ser difícil y requerir mucho time, la dificultad aumenta más que o (n) siendo n la sum de cambios en ambas twigs. En general, durante más de 1 mes debe tener un buen sistema de control de fuente, buenas interfaces / architecture de código o desarrolladores OCD o una combinación de esos tres.

Alnetworkingedor del 25% del time en un proyecto debe estar dedicado a la networkingucción de la deuda técnica, que en su mayoría incluye la refacturación del código. Las twigs de características son un problema durante la refactorización, porque una fusión de twigs de prerefactorización y posrefraccionamiento puede ser extremadamente difícil. Por esta razón, quiere asegurarse de que todas las twigs de características se fusionen antes de comenzar a refactorizar.