flux de travail git :fusionner et résoudre les conflits une fois

Question

Nous avons un flux de travail simple avec trois branches principales

staging c'est-à-dire l'environnement de test

master c'est-à-dire l'environnement de production

dev/XXX où XXX est le numéro du ticket

• Les clients enregistrent les tickets
• on crée une branche par exemple dev/2332
• nous travaillons + commit + push
• nous fusionnons le travail lorsqu'il est prêt dans staging
• le client approuve le travail sur staging
• nous fusionnons le travail dans master et le ticket est déployé en production

Le problème:

Si plusieurs développeurs travaillent sur leur dev/XXX branches;quand ils fusionnent dans staging, parfois, ils créent des conflits.Ils résolvent ces conflits lors de la mise en scène et du push.

Le problème est que lorsque le client approuve ces tickets spécifiques et que nous fusionnons le travail dans master, nous devons à nouveau régler les conflits

Important:

• nous ne pouvons pas fusionner la scène dans master -- à cause de tickets non approuvés
• toutes les branches par défaut sont créées à partir du dernier maître
• plusieurs tickets sont développés simultanément mais sont déployés une fois approuvés
• rebaser à partir du maître pour éviter les conflits n'est une option que si le travail a été approuvé + déjà déployé
• le rebasage à partir de la mise en scène est pas une option -- en raison de billets non approuvés

Des idées sur la façon de résoudre ce problème ?Notre flux de travail est-il défectueux ?Est-ce qu'il nous manque un git hack ?

En gros, je ne veux pas que l’équipe répète deux fois la même chose

Merci

Answer 1

Regarder branche par fonctionnalité.Vous devriez recevoir mon message sur ce sujet précis.J'ai également répondu à une question ici sur Partage du cache rerere

Answer 2

Vous devez garder master et staging aussi près que possible les uns des autres.Vous pouvez essayer de le gérer de la même manière que git lui-même. pu bifurquer.C'est lorsqu'une nouvelle tâche est terminée, la branche est supprimé, recréé à partir de master et toutes les fonctionnalités en attente d'approbation ont été fusionnées.L'avantage est que les branches ne divergent pas et qu'il n'y a aucun problème pour annuler la fusion des fonctionnalités rejetées.L'inconvénient est que vous ne pouvez pas baser votre travail sur cela, mais vous ne le faites pas de toute façon.

Lorsqu'un conflit survient, vous modifiez les branches de développement pour fusionner proprement et exécutez la fusion "octopus" (fusion avec plus de 2 parents), créant ainsi staging encore une fois, ou vous attendez que les dépendances ou les fonctionnalités conflictuelles soient approuvées avant d'essayer de préparer la dépendance.

Dans tous les cas, les branches de fonctionnalités doivent être rebasées sur (ou fusionnées avec) les dernières master juste avant de tenter de les mettre en scène.Ils ont été créés à partir du maître lors de leur création, donc les rebaser sur un maître ultérieur revient à dire qu'ils ont été démarrés plus tard et développés plus rapidement, ce qui ne serait évidemment pas faux.