Estamos usando Git Flow en nuestro último proyecto de iOS y estoy tratando de encontrar una forma de trabajar con QA para que puedan probar la última versión, así como probar una nueva función, sin tener que preocuparme por los errores corregidos qué rama.

En la actualidad, han estado probando enrelease/v1.0.1 rama, que tiene varios errores corregidos del originalrelease/v1.0. Al mismo tiempo, he estado trabajando en una nueva característica que se planeó para la versión v1.1, pero se separó dedevelop ramificarse al mismo tiempo querelease/v1.0.1 y por lo tanto no tiene ninguna corrección de errores.

Hoy, el departamento de control de calidad quisiera tomar mi nueva función para una prueba de manejo. Sin embargo, si les creo una compilación desde mi rama, ninguna de las correcciones de errores que han vuelto a probar y cerradas estará allí. Por lo tanto, recibiré una avalancha de quejas y pánico sobre los errores que se han reintroducido ... ¡Lo que quiero evitar!

Entonces, ¿cuál es la mejor manera de hacer que prueben esto? Podría fusionarmerelease/v1.0.1 en mi rama de características, pero luego debería asegurarme de no volver a fusionarme endevelop antes derelease/v1.0.1 ha sido lanzado ... Y supongo que hasta cierto punto, esto rompe la metodología Git Flow. Podría crear una rama completamente nueva solo para pruebas de control de calidad, que combina mi función conrelease/v1.0.1, pero ¿qué hago con los errores que encuentran en esta rama? ¿Dónde lo fusiono nuevamente después de la ronda de control de calidad?

Además de todo esto, tengo que considerar los números de compilación y los números de versión, para que tengan sentido. Actualmente, los números de versión son los que se usan para el lanzamiento, y los números de compilación se incrementan con cada nueva compilación para QA. Sin embargo, si están recibiendo compilaciones de dos ramas separadas, podría terminar con conflictos de números de compilación que causarían confusión.

¿Cuál sería la mejor manera de lidiar con estos problemas?