éviter/minimiser git merge conflits lorsque 2 successifs engage modifier les mêmes fichiers

Question

j'ai une situation comme suit [ce n'est pas un problème de programmation concrète, mais quelque chose que je prévois me arrivera bientôt]

1. Je suis affecté 2 tickets qui nécessitent l'ajout de deux fonctionnalités étroitement liées, par exemple la fonctionnalité 1 et la fonctionnalité 2, à un outil. L'ajout de ces deux fonctions nécessite l'édition de 95% des mêmes fichiers source
2. fonctionnalité 2 dépend des changements de fonctionnalité 1. par exemple if(feature1 flag enabled) foo; else bar;
3. Je viens de mettre en œuvre feature1 et envoyé un avis de code, l'examen du code tourne autour de 2-5 jours.Je suis sûr qu'il y aura quelques changements suggérés par le critiques
4. Cependant, alors qu'ils examinent la fonction 1, je veux commencer à mettre en œuvre la fonctionnalité 2

Comment ferais-je ceci de manière à éviter/minimiser les conflits de fusion douloureux? Je ne veux pas enregistrer/poster pour examiner les choses liées à la caractéristique 2 dans le processus d'adresser les commentaires d'examen pour la caractéristique 1.

Mon équipe utilise git, avec flux git.

[Pas une question hypothétique, problème réel]

Answer 1

Étant donné que les « changements qui doivent être mis en place pour mettre en œuvre fonction 2 dépendent des changements de fonction 1 », vous pouvez commencer fonction 2 en tant que dérivation de la fonction 1. De cette façon, vous séparez l'adressage des commentaires de révision pour la fonction 1 tout en travaillant sur la fonction 2, et vous commencez à travailler sur feature2 avec le code de fonctionnalité 1 déjà en place dans les fichiers communs.

Ensuite, lorsque l'examen de fonction 1 est terminée et il est sur le point d'être fusionnés, vous pouvez alors:

1. fonctionnalité de fusion 1 (pour développer, je suppose) puis rebasage fonction 2 sur la mise à jour développer

develop - - - - - - - - - - - - - - - - - o (merge feature 1) 
     \        /\ 
feature1 - o - o (for-review) - o (fix) - \ 
       \       \ 
feature2   - o - o - o - - - - - - - - -o (rebase) - o (continue) 

2. caractéristique rebasage 2 sur le commit final pour caractéristique une

develop - - - - - - - - - - - - - - - - - o (merge feature 1) 
     \        /
feature1 - o - o (for-review) - o (fix) - 
       \    \ 
feature2   - o - o - o - - - o (rebase) - o (continue) 

Notez que ce ne sera pas complètement éviter les conflits. Si les commentaires de révision pour feature1 nécessitaient un refactoring du code commun ou une refonte complète de l'implémentation, alors rebasing feature2 introduira certainement des conflits, mais au moins, il est localisé dans la branche feature2. Mais dans les cas où les commentaires sont pour la plupart syntaxiques ou, par exemple, la gestion des erreurs a été ajoutée, etc., il ne devrait pas y avoir de problèmes avec la rebase.