Aunque abogamos fervientemente por la integración continua en lugar de Gitflow, sabemos que subir cambios (commit) directamente al trunk y ejecutar los procesos de integración continua en una rama master puede ser ineficiente si el equipo es demasiado grande, si la construcción es lenta o inconsistente, o si el equipo carece de la disciplina para ejecutar el conjunto completo de pruebas localmente. En esta situación, una compilación fallida puede bloquear a múltiples personas o pares de desarrollo. En lugar de corregir la causa subyacente del problema (compilaciones lentas, incapacidad de ejecutar pruebas localmente o arquitecturas monolíticas que requieren que muchas personas trabajen en la misma área), los equipos generalmente confían en las ramas por funcionalidades (feature branch) para esquivar estos problemas. Desaconsejamos este tipo de ramas, ya que pueden requerir un esfuerzo significativo para resolver conflictos al integrar cambios e introducen ciclos de retroalimentación más largos y posibles errores durante la resolución de conflictos. En su lugar, proponemos utilizar compilaciones preliminares como alternativa: son compilaciones basadas en peticiones de cambios (pull requests) para “micro ramas” que existen sólo durante la ejecución del pipeline de compilación y que se abren con cada commit. Para ayudar a automatizar este flujo de trabajo, nos hemos encontrado con bots como Bors que automatizan la integración de cambios con master y la eliminación de la micro rama en caso de que su compilación tenga éxito. Estamos considerando este flujo, y también deberías hacerlo; pero no para resolver el problema incorrecto, ya que puede llevar al mal uso de las ramas y puede causar más daño que beneficio.
