Gitflow: branche de fonctionnalité avec un seul commit fusionné à l'aide de l'avance rapide

Je viens de le trouver moi-même aujourd'hui aussi. Il y avait un problème déjà soulevé et fermé pour cela ici : https://github.com/nvie/gitflow/issues/100 mais je suis d'accord que cela ne correspond pas au modèle de développement. Espérons que si suffisamment de gens font des histoires, nous pourrons changer quelque chose ici. (Je ne suis pas assez averti pour faire ce changement en privé.)

J'ai commencé à regarder les deux problèmes. Je ne sais pas encore quelle voie je préfère, mais une option vaut presque toujours mieux que pas d'option du tout, n'est-ce pas ?

Un indicateur est introduit pour cette fonctionnalité dans mon fork git-flow (édition AVH)
Mon fork a trop divergé pour en faire une demande d'extraction facile pour le gitflow de nvie,

Consultez le journal des

D'accord. Au moins, j'aimerais voir la justification derrière cela.

D'accord - le comportement n'est pas évident, en particulier pour les nouveaux utilisateurs de git flow.

L'une des raisons d'avoir cet indicateur est un flux de travail qui implique un processus de révision. J'aimerais pouvoir annoter la demande de fusion avec un numéro de ticket, même lorsque le ticket n'impliquait qu'un seul commit. Oui, des commits de fusion supplémentaires peuvent ajouter du bruit en général, mais dans un workflow comme celui-ci, il est important de remonter jusqu'à un ticket, sans avoir à nécessairement modifier le message de commit lui-même (puisque le numéro de ticket peut ne pas être là depuis le début)

J'ai été très mauvais pour commenter, mais à part mon observation initiale, je pense que beaucoup d'autres ont contribué leurs cas d'utilisation et ont davantage justifié l'utilité.

Dans l'état actuel des choses, la chose qui me perplexe est de savoir où apporter des correctifs et des améliorations - le projet git-flow d'origine n'étant apparemment pas maintenu et aucune des fourches n'a été bénie en tant que successeur.

Pour mémoire, je pense que le fork 'AVH' incluait quelque chose comme ce changement qui était assis derrière un drapeau (je crois désactivé par défaut), mais il y avait aussi un certain nombre de modifications tardives que j'ai vérifiées pour la dernière fois.

• tard -> grand

+1 pour au moins ajouter une option permettant à l'utilisateur de forcer --no-ff même si la branche ne contient qu'un seul commit :+1 :

J'avais du mal aujourd'hui à comprendre pourquoi je n'avais pas mon commit de fusion et pourquoi il a soudainement effectué une avance rapide, j'ai dû me demander ce que j'avais fait de mal, etc. .

Si je lance un correctif rapide qui ne prend qu'un seul commit et que je ne veux explicitement pas de commit de fusion et d'avance rapide, je commit simplement directement sur ma branche develop . J'ai toujours fait ça. Si je crée une branche de fonctionnalité, même pour un commit, c'est pour que cette branche soit conservée, pas pour disparaître comme par magie (à cause de l'avance rapide) lorsque je fusionne. Si je ne voulais pas de cette branche, je me serais engagé directement sur le développement et je n'aurais pas créé la branche de fonctionnalité depuis le début.

Au moins, veuillez ajouter un indicateur ou une entrée de configuration pour permettre à l'utilisateur de choisir le comportement qu'il souhaite, au lieu de désactiver de manière inattendue l'avance rapide dans certaines conditions (compréhensibles mais arbitraires) :wink:

Mon fork git-flow (AVH Edition) a la possibilité de définir des indicateurs par défaut, de cette façon vous pouvez toujours faire un --no-ff sans le taper. Voir le Wiki pour plus d'informations.

Mon fork a trop divergé pour en faire une demande d'extraction facile pour le gitflow de nvie,

Consultez le journal des

@petervanderdoes Merci.

En fait, pour être juste, je n'utilise pas la ligne de commande gitflow mais l' interface graphique SourceTree qui semble utiliser la ligne de commande gitflow @nvie en interne. Je ne sais pas si je peux faire en sorte que SourceTree utilise une autre version/exécutable git-flow et comment ?

En fermant le numéro 100, @nvie se trompe tout simplement : il commente que « le commit de fusion supplémentaire n'ajoute rien et ne fait que compliquer inutilement l'arborescence des branches » alors qu'en fait, le commentaire de la fusion est le seul enregistrement laissé pour les générations futures dénotant le fait que (a) une branche de fonctionnalité a été créée, et (b) quel était le nom de la branche de fonctionnalité. Sans une fusion explicite et sans avance rapide, l'historique du projet perd complètement l'information selon laquelle le commit était une branche, et était une fonctionnalité, du tout !

Ce serait bien de régler ça

Je serais tenté de supprimer l'option --ff explicite du cas de validation unique. Ensuite, la configuration de fusion git intégrée merge.ff=false peut être utilisée pour définir --no-ff pour toutes les fusions (y compris celles par fin de flux), avec la configuration git par défaut reproduisant le comportement actuel.

+1

À tout le moins, ce serait bien si cette "fonctionnalité" était documentée.

Tout progrès sur ce point, je sais que je ressasse un ancien, mais nous ne voyons aucun moyen d'utiliser sourcetree pour fermer une fonctionnalité sans faire avancer rapidement la fusion. Il y a un réglage dans les prefs, mais il ne semble pas le respecter

+1

+1

Voir « Ce référentiel est-il mort ? #6340 »

Il s'avère que vous pouvez simplement utiliser git sans cela ! ??

Non documenté, et ne donne pas une option d'utilisation.
Ce type de décisions doit être prise du côté de l'utilisateur. Pourquoi ne pas mettre une petite case à cocher dans la boîte de dialogue "Terminer la version" et si vous êtes vraiment un grand fan de cette fonctionnalité laissez-la être cochée par défaut mais comme je ne le suis pas, je peux la décocher, non?

A chaque nouvelle version, c'est la première chose que je vérifie :D et ce n'est jamais là :/

Je viens de découvrir qu'il y a aussi une case à cocher pour cela dans les préférences. Donc pas besoin de le vérifier pour chaque fusion de branche.