GitFlow: fusionnez en toute sécurité les modifications apportées à une branche de fonctionnalité
Récemment, j'ai commencé à travailler sur de grandes fonctionnalités, j'ai donc créé un nouveau feature/xyz branche. Le problème est que cette fonctionnalité est grande, il me faudra donc environ 3 mois pour la terminer. Je voudrais fusionner en toute sécurité les progrès réalisés dans develop vers ma branche de fonctionnalité, sans craindre que les modifications de la branche develop annulent les mises à jour que j'ai déjà faites dans ma branche de fonctionnalité. Ma précédente tentative de fusion de develop vers feature/xyz a abouti à quelques modifications que j'ai déjà apportées à la nouvelle fonctionnalité en cours de restauration.
Quelle serait la commande pour y parvenir? Merci
La seule sécurité réside dans les fusions apprises, exigeantes et fréquentes.
Vous seul comprenez comment le code sur develop et feature/xyz aligne, personne d'autre. C'est seulement vous qui pouvez fusionner correctement les deux flux de manière éclairée. Même avec les stratégies de fusion par défaut, qui sont beaucoup moins dangereuses que -S ours ou -X theirs vous devez toujours revoir le résultat.
Vous aurez peut-être besoin d'aide, bien sûr, et git vous en proposera. Par exemple, vous pouvez utiliser les résolutions enregistrées git - rerere pour vous aider à prendre la même décision de fusion correcte après en avoir fait une initialement.
Un modèle assez courant et relativement simple, utilisant les noms que vous avez fournis pour les succursales, pourrait fonctionner pour vous comme ceci,
developest la branche où se produit l'essentiel du développementxyzest la branche où vous développez la fonction xyzxyz_stageest la branche où vous fusionnez le codedevelopetxyz, en gardant cette branche stable en ligne avec les points stables respectifs dedevelopetxyz. Il s'agit également de la branche que vous fusionnerez éventuellement pour développer lorsque vous serez prêt à publier la fonctionnalité xyz ou une partie de celle-ci.
Ce qui précède suppose que non seulement vous fusionnez xyz en xyz_stage mais que vous fusionnez également develop en xyz_stage de temps en temps et assurez-vous que les parties de xyz jusqu'à présent libérées dans xyz_stage fonctionne et passe les tests appropriés avec le code de develop.
Néanmoins, vous devez toujours choisir comment rendre la branche xyz, où vous travaillez sur la fonctionnalité, consciente de la progression du développement.
L'option la plus propre est - ne le faites pas savoir. Voilà pourquoi vous avez xyz_stage où les deux flux de développement se rejoignent. Cette approche est faisable et sensée tant que le développement de xyz n'est pas prolongé.
La deuxième option consiste à fusionner xyz_stage de nouveau dans xyz lorsque vous êtes satisfait de la branche intermédiaire. De cette façon, vous aurez un point stable que vous pourrez continuer et développer la fonction xyz en haut.
Voici une illustration simple du processus, avec des commentaires:
Utilisation git merge -s recursive -X ours . Cela entraînera toujours la résolution des conflits dans les deux branches à l'aide de la version du répertoire extrait (feature/xyz dans ce cas).
Important : contrairement à votre titre, cette stratégie n'est pas forcément "sûre" : les modifications de develop peuvent entrer en conflit avec celles de feature/xyz. Comme toujours, assurez-vous de tester correctement les modifications fusionnées.
D'après mon expérience, la seule solution "sûre" consiste à toujours inspecter et tester manuellement le résultat de toute fusion. --no-commit mettra en scène la fusion et vous permettra de l'inspecter avant de valider, ou vous pouvez réinitialiser/modifier, ce qui vous semble plus pratique. Obtenir un outil de fusion à trois peut être très utile. Il y a tout simplement trop de façons dont les choses peuvent se briser sans qu'il y ait des conflits de fusion, que le fait de s'appuyer sur la fusion automatique vous causera des ennuis. Si vous avez une couverture de test à 100%, bien sûr, vous pouvez être un peu plus détendu, mais combien de projets peuvent vraiment prétendre à cela? ;-)