J'ai l'impression en fait que tu cherches une approche par patches.
Chaque "features" branches est en fait un patch disponible pour intégration/test.
Certes il existe plusieurs petit commits pour une seul branche mais le diff (head - master) représente un seul et unique patch que vous voulez appliquer ou pas.
Dans ce context, j'aurai plutôt une approche de ce type :
Une branche master qui ne contient que les fonctionnalité validé (et donc finale).
Une branche par fonctionnalité. Au maximum basé sur la tête le master HEAD. Éventuellement, si une fonctionnalité B dépend d'une fonctionnalité A, alors branche_B est basée sur branche_A au lieu de master.
Un magnifique script que je vous laisse développer qui merge le tout (les fonctionnalité que tu veux tester) dans une branche d'intégration "temporaire"
si tes tests fonctionnels sont bon, master fast-forward sur la branche d'intégration. Les branches de fonctionnalités non mergées sont rebasé sur le nouveau HEAD
si tes tests fonctionnels passent pas, tu vires la branches (ou tu la laisse de coté pour l'historique) et tu créés une nouvelle branche d'intégration pour les tests suivants.
C'est globalement la même chose que ce que tu as, mais sans branche d'intégration "réelle". Les branches d'intégrations sont temporaires et privées (pour les tests).
Le fait que tes merges de features soient automatisés doit améliorer le git-rerere. En effet, si tu changes juste un truc dans une branche, tu repars toujours du même point et tu applique tout tes patchs/merge dans le même ordre. Donc tu te retrouves à corriger que les conflits ajoutés par le changement que tu viens de faire.
Tu simplifies aussi le boulot d'intégrateur puisque qu'il se retrouve à "seulement" décider quels patches tester, lancer le script et corriger les nouveaux conflit.
Au niveau outils, il y a stgit qui gèrent une séries de patch par dessus une tête de branche. Chaque patch est versionné dans une branche git séparée. Je sais pas si ça correspond à ton besoin car stgit construit lui-même les branches en fonctions des fichiers .patch que tu lui donne à manger, mais ça peut donner des idées.
# Patch
Posté par GaMa (site web personnel) . En réponse au journal Git workflow, rebase, conflits et rôle d'intégrateur. Évalué à 3.
J'ai pas de solution toute faite mais une piste.
J'ai l'impression en fait que tu cherches une approche par patches.
Chaque "features" branches est en fait un patch disponible pour intégration/test.
Certes il existe plusieurs petit commits pour une seul branche mais le diff (head - master) représente un seul et unique patch que vous voulez appliquer ou pas.
Dans ce context, j'aurai plutôt une approche de ce type :
C'est globalement la même chose que ce que tu as, mais sans branche d'intégration "réelle". Les branches d'intégrations sont temporaires et privées (pour les tests).
Le fait que tes merges de features soient automatisés doit améliorer le git-rerere. En effet, si tu changes juste un truc dans une branche, tu repars toujours du même point et tu applique tout tes patchs/merge dans le même ordre. Donc tu te retrouves à corriger que les conflits ajoutés par le changement que tu viens de faire.
Tu simplifies aussi le boulot d'intégrateur puisque qu'il se retrouve à "seulement" décider quels patches tester, lancer le script et corriger les nouveaux conflit.
Au niveau outils, il y a stgit qui gèrent une séries de patch par dessus une tête de branche. Chaque patch est versionné dans une branche git séparée. Je sais pas si ça correspond à ton besoin car stgit construit lui-même les branches en fonctions des fichiers .patch que tu lui donne à manger, mais ça peut donner des idées.
Matthieu Gautier|irc:starmad