Puede que esto no funcione para tu caso de uso, pero como intentamos fusionar a master con frecuencia y no dejar ramas por mucho tiempo, hemos tenido muy buena suerte con esta metodología.
Estamos utilizando Azure DevOps como nuestra herramienta de construcción, y empujando las construcciones en AppCenter.ms como nuestra herramienta de distribución para las construcciones que no son de lanzamiento. Para las compilaciones de lanzamiento, las enviamos directamente a la App Store.
AppCenter.ms le permite crear "grupos de distribución", que son básicamente una lista de las direcciones de correo electrónico que desea recibir notificaciones cuando se cargue una nueva compilación que "se dirija" a ese grupo. Cada grupo tiene un GUID único y si usas Azure DevOps y su .azure-pipelines.yml (o configuras manualmente una build a través de la UI, aunque eso es un proceso muy laborioso), puedes usar la tarea de AppCenter con una condición que comprueba el nombre de la rama y despliega a IDs de grupos específicos basados en la rama que se está construyendo.
Una de las cosas que nos facilita esto es que estamos utilizando "certificados de distribución de empresa", ya que estos no requieren la inscripción de dispositivos individuales como lo hacen los certificados ad hoc o de desarrollador. La otra pieza que podría ser importante, si un usuario puede instalar versiones de la aplicación de diferentes grupos que debe tener un ID de paquete diferente (y por lo tanto otro perfil de aprovisionamiento) para cada versión, de lo contrario se clobber entre sí en el dispositivo del usuario. Este es un requerimiento de Apple (pero Android tiene un requerimiento de nombre de paquete único similar).
En nuestro caso, debido a que estos viven en nuestra cuenta Enterprise (no en la AppStore pública), tenemos com.company.appname.test y com.company.appname.prodtest que para nuestros propósitos ejecutan el mismo código, pero apuntan a diferentes entornos de backend (URLs) para nuestras APIs.
