La gestion des correctifs lorsque la branche de développement est très différente de celle du maître?
J'utilise le modèle de branchement "Git Flow", avec une branche master et une branche develop. Je travaille sur une nouvelle version majeure, donc ma branche de développement est très différente de ma branche principale. Cela crée un problème chaque fois que j'ai besoin de créer un correctif sur la branche principale et de le fusionner à nouveau dans develop. Il y a presque toujours des conflits et cela devient une vraie douleur.
Quelle est la meilleure façon de gérer cela? Il serait plus facile pour moi de faire les petits changements de correctif lors du développement manuellement, puis de tout fusionner dans master lorsque je serai prêt sans réintégrer master dans develop. Est-ce possible?
La manière la plus simple d'obtenir certains commits d'une branche à une autre est sélection de cerise .
En supposant que votre correctif dans master a le hachage de validation HASH et que vous souhaitez prendre ce correctif dans votre branche devel, faites un git checkout devel suivi d'un git cherry-pick HASH. C'est ça.
Si vous voulez prendre toutes les modifications de master en devel, vous pouvez y parvenir avec
git checkout devel
git rebase master
Si vous avez le scénario opposé (vous créez un correctif pendant le développement dans une branche devel et souhaitez prendre ce correctif dans master avant que devel soit complètement fusionné dans master), le workflow est assez similaire. En supposant que le correctif dispose du hachage HOTFIX_HASH, procédez comme suit:
git checkout master
git cherry-pick HOTFIX_HASH
Maintenant, la validation est présente dans master et devel. Pour contourner cela, tapez
git checkout devel
git rebase master
et le commit disparaîtra de devel car il est déjà présent dans master.
Mon flux de travail général pour cette situation consiste à créer un bug-fix branche de master qui résout le problème. Une fois qu'il est prêt, fusionnez-le dans master puis fusionnez master dans develop.
Cela suppose que votre correction de bogue est presque un à un entre le code dont il a besoin pour changer dans les deux branches. Si tel est le cas, vous pouvez toujours essayer un git merge -s ours master (voir page de manuel ) dans develop pour que la branche develop soit prioritaire.
J'utilise un processus similaire pour gérer les versions de correction de bogues sur un projet open source sur lequel je travaille. master est toujours en avance sur l'endroit où le correctif de bogue doit être appliqué, donc je crée une branche à partir de la balise qui a besoin du correctif, j'applique le correctif et la relâche, puis je retague et fusionne la nouvelle balise dans master. Cela provoque un conflit en raison des numéros de version, mais peut être évité avec la commande ci-dessus.
J'espère que cela pourra aider.
Je suis généralement le suivant guide qui correspond assez bien dans la plupart des cas et évite au maire des problèmes de conflits et de gros changements .
Si vous pouviez travailler sur les branches feature et les fusionner dans development uniquement avant la création d'une branche release (ce qui signifie que vous préparez en fait une version) ... cette méthode devrait éviter la plupart des conflits de fusion que vous rencontrez.
Étant donné que les changements de rupture se produiraient à un feature-breaking branche, vous NE POUVEZ avoir de conflits qu'une seule fois au moment où cette feature-breaking la branche est fusionnée dans le développement. Et vous pouvez également fusionner development dans la branche release à tout moment pour la maintenir à jour.
Vous serez également cool de fusionner dans development tous les hotfix-branches que vous avez avec un minimum ou aucun conflit.
Le guide que j'ai partagé sur le lien avant met l'accent sur le fait de ne jamais fusionner de development vers master ou en arrière. Gérez toujours vos versions via une branche release.