Este é o problema exato que eu tenho com o fluxo do gitflow e do GitHub, e parece que com os aplicativos da web isso acontece com frequência - ou mais como a norma. Parece que você resolveria esse problema retroativamente (mencionado acima) ou proativamente (exemplo abaixo).
Eu criei 'ramificações de pacote' além das ramificações de gitflow padrão. O pacote consiste em todos os recursos que estão prontos para uat / qa. Uma lista de recursos uat / qa é criada. Eles são mesclados no pacote temporário e esse pacote é implantado em uat / qa. Qualquer correção de bugs acontece no ramo de recursos original, e isso é remetido de volta ao pacote e implantado. Isso separa a próxima versão, bem como permite testar esses recursos antes de encontrar o caminho para o ramo de desenvolvimento. As ramificações aprovadas obtêm uma solicitação de pull no desenvolvimento - seguindo o processo de gitflow. Os recursos prontos para teste podem ser adicionados ou removidos do ramo de pacote temporário
e reimplantado.
- Isso mantém o mestre sempre refletindo o estado pronto para produção (pode automatizar com gancho)
- O desenvolvimento sempre reflete o próximo candidato a lançamento entregue (e testado)
Contras incluem o gerenciamento da lista de pacotes e a adição de outro tipo de filial; no entanto, além da correção retro, que acho que é tarde demais, esta parece ser a solução mais viável.
Com um complemento de GUI, pode ser ideal marcar ramificações de recursos por implantação de pacote - com a automação em mente.