Il semble que vous ayez quelques problèmes ici:
1. Identification des fonctionnalités d'une version spécifique
Il s'agit d'un problème de gestion de projet et d'un problème de coordination. Est-ce que cette fonction soit libéré avant, en même temps que, ou après cette autre fonction? Si les versions veulent se produire une fonctionnalité à la fois, identifiez-le. Si les fonctionnalités vont être regroupées dans des versions, déterminez quels sont les regroupements et appliquez-les aux développeurs et aux décideurs. Utilisez votre système de suivi des problèmes ou de billetterie pour baliser les versions. Expliquez clairement que si une fonctionnalité d'une version spécifique est interdite, alors toutes le sont.
2. Stratégies de branchement
Git-flow est la réponse facile à de tels problèmes, et souvent les gens utilisent une variante de git-flow même s'ils ne savent pas ce que c'est. Je ne vais pas dire que c'est un fourre-tout pour tous les problèmes, mais cela aide beaucoup.
On dirait que vous rencontrez un problème avec les stratégies de publication non déterministes, où les fonctionnalités sont approuvées en scattershot et quelque chose qui a commencé le développement il y a longtemps pourrait être publié après quelque chose qui a commencé plus récemment - les fonctionnalités de saut de grenouille.
Les branches de fonctionnalités à longue durée de vie ou les branches de versions simultanées sont probablement la meilleure réponse à ce type de problèmes. Fusionnez (ou rebasez, si vous êtes à l'aise avec) la dernière version de master dans vos branches de longue date. Faites attention à ne fusionner que les fonctionnalités déjà en ligne, sinon vous rencontrerez les problèmes que vous rencontrez actuellement (trop de fonctionnalités mélangées sur une branche).
Les branches "Hotfix" ou "bugfix" sont une partie essentielle de ce processus; utilisez-les pour de petites corrections ponctuelles qui ont un cycle d'assurance qualité court.
D'après votre description, il pourrait même être préférable de ne pas maintenir une branche officielle de «développement». Plutôt, branchez toutes les fonctionnalités hors du maître et créez des branches de versions fusionnées une fois qu'une version est identifiée.
3. Environnements
Ne faites pas correspondre les branches git à vos environnements, sauf pour la production == master. La branche «développement» doit être supposée cassée. Les branches de publication sont poussées pour tester les environnements, qu'il s'agisse d'un environnement QA ou d'un environnement de transfert. Si vous en avez besoin, envoyez une branche de fonctionnalité spécifique à un environnement.
Si vous avez plusieurs branches de fonctionnalités qui doivent être publiées séparément mais sont testées en même temps ..... ¯ \ _ (ツ) _ / ¯ .... vous lancez un autre serveur? Peut-être les fusionner ensemble dans une branche jetable ... valider les correctifs / modifications dans les branches originales et re-fusionner dans la branche jetable; faire l'approbation finale et l'UAT sur les branches de publication individuelles.
4. Suppression de fonctionnalités non approuvées d'une succursale
C'est ce que les pensées ci-dessus tentent d'éviter, car c'est sans aucun doute la chose la plus douloureuse à essayer. Si vous êtes chanceux, les fonctionnalités ont été fusionnées dans vos branches de développement ou de test de manière atomique à l'aide des validations de fusion. Si vous n'avez pas de chance, les développeurs se sont directement engagés dans la branche développement / test.
De toute façon, si vous vous préparez pour une libération et avoir des changements non approuvés, vous aurez besoin d'utiliser Git pour reculer les commits non approuvés de la branche de sortie; la meilleure idée est de le faire avant de tester la version.
Bonne chance.