Hace tiempo que somos defensores de ramas de desarrollo de corta duración que son integradas frecuentemente en la rama principal del código, preparada para ser desplegada en cualquier momento. Esta práctica de desarrollo basada en trunk-based development va muy de la mano con integración continua y, cuando las condiciones lo permiten, se obtienen ciclos de feedback más rápidos y un flujo de desarrollo más eficiente. Sin embargo, no todo el mundo está a favor de este enfoque, y muchas veces tenemos que adaptar nuestro estilo a las prácticas de nuestros clientes. Esto incluye crear ramas de larga duración junto con pull requests que se deben revisar y aprobar manualmente antes de ser fusionados en la rama principal. En estas situaciones, utilizamos la nueva funcionalidad GitHub merge queueque nos permite encolar pull requests e integrarlos en una rama especial en el orden en que se recibieron. También tenemos la opción de automatizar nuestros propios merge checks para evitar commits incompatibles. Básicamente simula trunk-based development (aunque las PR no se hayan fusionado aún en la rama principal del código) y permite al equipo probar sus cambios junto con su contexto sin tener que esperar a que se apruebe ese pull request. Con GitHub merge queue, obtienes los beneficios del trunk-based development incluso cuando no puedes practicarlo por completo.
