Les branches de fonctionnalité sont-elles la solution ultime ?

Le flux de travail commun pour git (git flow) utilise des branches de fonctionnalité, où une branche distincte est créée pour chaque nouvelle fonctionnalité. Les développeurs implémentent de nouvelles fonctionnalités sur ces branches isolées, puis fusionnent leurs modifications dans la branche main ou master .

Les avantages de ce flux de travail sont clairs : une branche distincte peut être facilement déployée et testée dans l'environnement QA, et si des bogues critiques sont détectés, elle ne sera tout simplement pas fusionnée dans la branche main . Les problèmes peuvent être résolus et le code amélioré dans la même branche.

Pendant ce temps, la branche principale reste constamment déployable et protégée de ces problèmes.

Malheureusement, cette stratégie a un inconvénient important : les conflits de fusion. Avec les branches à longue durée de vie, qui sont inévitables à un moment donné, ces conflits peuvent être trop difficiles à résoudre pour qu'il devienne plus facile de se débarrasser complètement de la branche et de repartir de zéro.

De plus, lorsqu'il y a beaucoup de conflits, le résultat de la fusion peut être imprévisible.

Cependant, ce n'est pas la seule stratégie possible, et cet article couvrira une autre façon de gérer les nouvelles fonctionnalités du produit sans les inconvénients énumérés ci-dessus.

Pourquoi les conflits de fusion se produisent-ils ?

Selon la conception de Git, les conflits de fusion se produisent lors de la fusion lorsque les branches ont un contenu différent dans la même ligne de fichier.

Pour illustrer cela, considérons un scénario dans lequel deux équipes implémentent des mises à jour du même service. L'équipe A intègre la prise en charge des cartes de crédit, tandis que l'équipe B réorganise la page de profil utilisateur. Il semble que ces fonctionnalités n'aient rien à voir les unes avec les autres.

Cependant, il s'avère que le code lié au paiement était auparavant situé au même endroit que le code de la page de profil. Les deux équipes ont donc extrait leur code dans des branches distinctes et ont réécrit l'intégration.

Maintenant, la question est de savoir qui sera le premier à fusionner ses modifications dans la branche main et à prétendre que le problème n'est pas de son côté tandis que l'autre équipe essaie de résoudre le conflit qui en résulte ?

Développement basé sur le tronc

Dans l'ensemble, il est impossible d'éviter les conflits de fusion, mais nous pouvons certainement faciliter leur résolution en utilisant la règle bien connue suivante :

En termes Git, cela signifierait que nous devons fusionner aussi souvent que possible (idéalement à chaque commit). Et bien sûr, les conflits se produiront plus souvent dans ce cas, mais les résoudre sera beaucoup plus facile.

C'est ce qu'on appelle le développement basé sur le tronc et signifie pousser les modifications directement vers la branche main et éviter d'utiliser des branches lorsque cela n'est pas nécessaire.

Dans l'exemple ci-dessus, si les deux équipes poussaient régulièrement leurs modifications à la branche main , elles remarqueraient rapidement qu'elles essayaient de modifier le même fichier.

Plus encore, ils auraient pu éviter complètement les problèmes. La deuxième équipe aurait commencé à apporter ses modifications après que la première équipe ait déjà modifié le fichier, compte tenu de ces mises à jour.

Un lecteur attentif pourrait se demander : tout sonne bien, mais comment procède-t-on pour tester ? Les branches par fonctionnalité permettent de tester l'intégralité de la nouvelle fonctionnalité de manière isolée avant la publication ; si nous intégrons continuellement des changements dans la branche main , il n'y aura aucune chance pour cela.

Présentation des indicateurs de fonctionnalité

Un indicateur de fonctionnalité, ou une bascule de fonctionnalité, est un simple indicateur dynamique qui permet de basculer la fonctionnalité particulière lors de l'exécution. Généralement, les indicateurs de fonctionnalité permettent également d'activer ou de désactiver des fonctionnalités pour des groupes spécifiques d'utilisateurs, tels que les ingénieurs QA, le personnel, des clients spécifiques, etc.

Les drapeaux de fonctionnalité présentent plusieurs avantages supplémentaires :

• Déploiement sans risque

• Tests plus fiables directement en production

• Annulez rapidement les modifications si nécessaire.

L'utilisation d'indicateurs de fonctionnalité rend les changements poussés vers la branche main plus sûrs. Tant que l'indicateur de fonctionnalité est désactivé, les modifications n'affectent personne.

Cette technique permet de travailler directement avec la branche main ou de créer des branches éphémères. Ainsi, les conflits de fusion deviennent assez rares et se résolvent rapidement.

Conclusion

En résumé, le développement basé sur le tronc combiné avec des indicateurs de fonctionnalité est une excellente technique qui permet d'éviter de nombreux problèmes provoqués par des modifications conflictuelles dans les branches de fonctionnalité.

Cependant, comme toujours, il n'y a pas de solution unique. Cela fonctionne pour un petit nombre d'équipes qui travaillent dans le même référentiel - augmenter ce nombre nécessite généralement quelques ajustements.

De plus, il est toujours possible d'utiliser les deux méthodes : utilisez des branches de fonctionnalité ou des indicateurs de fonctionnalité en fonction de la situation et de la tâche spécifiques.