Gitflow: fonctionnalité terminer de ne pas faire de fusion --no-ff

Salut Scott,

De par sa conception, git-flow utilise l'option --no-ff lors de la fusion afin d'enregistrer que les commits appartiennent historiquement. Cependant, lorsque la branche de fonctionnalité ne contient qu'un seul commit, le commit de fusion supplémentaire n'ajoute rien et ne fait que compliquer inutilement l'arborescence de la branche. Ainsi, pour les branches à validation unique, les fusions rapides sont effectuées comme si la validation avait été effectuée directement sur develop .

Acclamations,
Vincent

Salut Vincent,

Je peux certainement comprendre la pensée derrière cette conception, mais je pense que le choix de la création ou non du commit de fusion doit être dicté par le choix de l'utilisateur de démarrer une branche de fonctionnalité. Parfois, je peux apporter des modifications rapides sur la branche de développement, mais je choisirai de créer une branche de fonctionnalité _spécifiquement_ parce que je veux voir le commit de fusion. Je peux ne faire qu'un seul commit dans une branche de fonctionnalité, mais ce n'est peut-être pas ce que, en tant qu'utilisateur, je considère comme suffisamment insignifiant pour justifier de ne pas tenir compte d'un commit de fusion explicite.

En fin de compte, je pense que le choix devrait être celui de l'utilisateur, et je pense que l'utilisateur exprime un choix différent en utilisant une branche de fonctionnalité plutôt qu'en s'engageant rapidement dans la branche de développement.

Tous les pointeurs sur l'endroit où je pourrais aller dans la base de code pour effectuer ce changement sous une forme privée seraient très appréciés !

Merci beaucoup pour un excellent outil!
-Scott

C'est là que la magie opère : https://github.com/nvie/gitflow/blob/develop/git-flow-feature#L310

Je ne vais pas ajouter d'option pour faire fusionner explicitement les branches de fonctionnalité à validation unique avec --no-ff, car je ne pense toujours pas que cela ajoute quoi que ce soit (autre que la complexité supplémentaire d'un autre indicateur de ligne de commande), mais n'hésitez pas à en faire un changement privé si vous insistez dessus.

Acclamations,
Vincent

Merci Vincent ! J'apprécie le pointeur !

Meilleur,
Scott

Si je peux ajouter mes 5 cents,

J'aimerais beaucoup avoir une option pour avoir un commit de fusion même lorsque vous terminez une fonctionnalité de commit.

Dans la façon dont j'utilise git flow, mes fonctionnalités incluent dans leur nom le numéro de ticket sur lequel je travaille. Lorsque je termine une fonctionnalité, j'aimerais beaucoup voir le commit de fusion spécifiant le nom de la fonctionnalité (qui inclut le numéro de ticket).

Ceci est utile pour retracer chaque validation jusqu'au ticket réel sans avoir à écrire le numéro du ticket dans chaque message de validation.

@DonGiulio Je ne sais pas si vous l'avez déjà vérifié, mais je suis presque sûr que l'édition AVH fait ce que vous voulez.

Merci, je ne savais pas, je vais regarder.

J'opte également pour simplement ajouter une option pour avoir un seul comportement sans engagement. Ce serait bien si vous pouviez reconsidérer cela.

(Je ne sais pas ce qu'il y a d'autre dans l'édition AVH).

@nvie Puis-je savoir pourquoi ?! "_Je ne pense toujours pas que cela ajoute quoi que ce soit_"
Honnêtement, j'ai pensé que lorsque des tas de gens pensent que cela ajoute quelque chose et que certains pensent que nous n'ajoutons pas une option quelque part ou au moins le documentons afin que les gens n'aient pas besoin de le trouver par essais et erreurs. Cela ne peut pas être une si grosse décision à prendre !

Si l'utilisateur s'est donné la peine de créer une fonctionnalité et a choisi d'y faire un seul commit, cela signifie qu'il avait besoin que ce soit ainsi (disons pour des raisons de conservation de l'historique visuel) et de ne pas pousser directement au développement . Je dirais le contraire et ignorer le chemin emprunté par l'utilisateur n'a pas de sens.

Auriez-vous envie d'élaborer ? Nous devrions convenir que tout le monde ne voudra peut-être pas se séparer d'un travail aussi solide à cause de changements aussi mineurs.

@Mehradzie Il n'y a pas eu de commit sur ce repo depuis 5 ans. L'édition AVH est la fourche de prédilection depuis un certain temps maintenant et est assez stable. Je ne retiendrais pas mon souffle pour une réponse ici, encore moins un changement de code.

@jawshooah pour être honnête, je n'ai même pas vérifié le nom du dépôt lorsque je me suis retrouvé ici car je poursuivais le même problème dans SourceTree.
Est-ce que gitflow est utilisé par SourceTree pour faire ses flux ? Je suis un peu confus en ce moment :D
Et si c'est le cas, peut-il me couper et changer comme vous l'avez suggéré d'utiliser le travail d'autres repos à la place !

@Mehradzie AFAIK SourceTree intègre une version légèrement modifiée de la version originale de nvie. Il y a des demandes en suspens pour qu'ils mettent à jour vers la version AVH (voir ici et ici ).