Estamos usando o Git Flow em nosso projeto iOS mais recente e estou tentando descobrir uma maneira de trabalhar com o controle de qualidade para que eles possam testar a versão mais recente e testar um novo recurso, sem ter que se preocupar com quais bugs foram corrigidos. que se ramificam.

Atualmente, eles têm testado norelease/v1.0.1 ramo, que possui vários bugs corrigidos do originalrelease/v1.0. Simultaneamente, eu tenho trabalhado em um novo recurso que foi planejado para a versão v1.1, mas foi ramificado dodevelop ramificar ao mesmo tempo querelease/v1.0.1 e, portanto, não possui nenhuma das correções nele.

Hoje, o departamento de controle de qualidade gostaria de levar meu novo recurso para um test drive. No entanto, se eu criar uma compilação do meu ramo, nenhuma das correções que eles testaram e fecharam novamente estará lá. Portanto, vou receber uma avalanche de reclamações e pânico sobre bugs que foram reintroduzidos ... O que eu quero evitar!

Então, qual é a melhor maneira de fazê-los testar isso? Eu poderia fundirrelease/v1.0.1 no meu ramo de recursos, mas devo garantir que não volte adevelop antesrelease/v1.0.1 foi lançado ... E acho que, até certo ponto, isso quebra a metodologia Git Flow. Eu poderia criar uma ramificação completamente nova apenas para teste de controle de qualidade, que mescla meu recurso comrelease/v1.0.1, mas o que devo fazer com os bugs que encontrarem neste ramo? Onde o mesclo novamente após a rodada de controle de qualidade?

Além de tudo isso, tenho que considerar os números de compilação e os números de versão, para que eles façam sentido. Atualmente, os números de versão são os usados para a liberação e os números de compilação são incrementados a cada nova compilação para o controle de qualidade. No entanto, se eles estiverem recebendo compilações de duas ramificações separadas, eu poderia acabar com conflitos de número de compilação que causariam confusão.

Qual seria a melhor maneira de lidar com esses problemas?