Un élément clé que git-flow était censé aborder était la capacité de raisonner sur le rôle d'une branche donnée, et ce à quoi elle dérivait et fusionnait.
Idéalement, toutes les branches fusionnent avec la ligne de code à partir de laquelle elles ont été fusionnées. Il s'agit généralement d'une fusion à partir de la ligne principale (dans git-flow, c'est dev). Fonctionnalité: branchez et fusionnez les branches depuis dev, libérez les branches et fusionnez depuis dev (avec une fusion supplémentaire vers master). Branche de correctifs et fusion depuis master (avec cette fusion supplémentaire vers dev).
Chaque ligne de code se ramifie et fusionne avec son parent. Une ligne de code peut extraire du code à partir d'autres lignes de code à tout moment si cela est nécessaire.
Si la branche d'une branche de fonctionnalité est un "Je veux explorer cette façon de résoudre un problème dans cette branche de fonctionnalité" - c'est parfait. Il dérive de la branche de fonctionnalité, valide du code et fusionne dans la branche de fonctionnalité (ou est supprimé).
- branche à partir de la fonction
- explorer l'idée
- fusionner pour présenter
Ce que vous voulez éviter cependant, c'est quelque chose qui ressemble à:
- branche à partir de la fonction requise
- travailler sur le code
- fusionner à partir du développeur une fois la fonctionnalité requise terminée
- vérifier la fonctionnalité (et les validations supplémentaires) dans la branche de fonctionnalité
- fusionner avec dev
La raison en est que le début et la fin ne correspondent pas - cela rend un peu plus difficile de comprendre ce que c'est et ce que c'était. Pas impossible, mais cela prend juste un peu plus de temps pour que quelqu'un comprenne son rôle.
Cependant, s'il s'agit d'une nouvelle fonctionnalité qui dépend du code qui n'est pas encore trouvé dans dev, le flux doit être:
- branche de dev
- fusion de la fonction requise
- travailler sur le code
- fusionner à partir du développeur une fois la fonctionnalité requise terminée
- vérifier la fonctionnalité (et les validations supplémentaires) dans la branche de fonctionnalité
- fusionner avec dev
Notez que cela commence par une branche de dev et se termine par une fusion vers dev.
Cela dit, la meilleure chose à faire est probablement d'éviter de faire une fusion d'une fonctionnalité à une autre. Branchez la fonctionnalité, effectuez les préliminaires nécessaires ... et attendez.
- branche de dev
- travailler sur le code
- fusionner à partir du développeur une fois la fonctionnalité requise terminée
- vérifier la fonctionnalité (et les validations supplémentaires) dans la branche de fonctionnalité
- fusionner avec dev
Cela fournit l'ensemble de branches et de code le plus stable.
Quelque chose à considérer pour les travaux futurs serait d'avoir une fonctionnalité pour publier les interfaces nécessaires pour l'interopérabilité avec d'autres fonctionnalités - même si le code d'implémentation n'est pas complet. Cela serait fusionné avec dev, puis la fonctionnalité requise pourrait fonctionner à partir de ces interfaces, tout comme la fonctionnalité future. Cela permettrait probablement à la fonctionnalité future de progresser davantage (codage par rapport aux interfaces, test par rapport aux stubbs qui implémentent les interfaces) que si elle devait attendre que la fonctionnalité requise fusionne pour se développer.