Réutiliser une branche fusionnée, bonne pratique?

Actuellement, je créais une nouvelle branche chaque fois que je devais ajouter une nouvelle fonctionnalité à mon application.

Lorsque ma fonctionnalité est terminée et fonctionnelle, je la fusionne avec la branche principale.

Mais plus tard, lorsque je devrai mettre à jour cette fonctionnalité (comme une amélioration), est-il préférable de créer une nouvelle branche ou dois-je rebaser la précédente avec le maître, la mise à jour se fusionne-t-elle à nouveau?

Par exemple, j'ai une branche appelée modélisation-membre dans une application Ruby on Rails. Plus tard, je dois ajouter des attributs au modèle de membre (créé dans cette branche). Que devrais-je faire? Rebaser cette branche avec le maître, mettre à jour le modèle et le fusionner à nouveau ou simplement créer une nouvelle branche?

Créez une nouvelle branche, car:

• Une nouvelle branche est moins susceptible d'avoir des conflits de fusion lorsque vous avez terminé et que vous souhaitez le fusionner en tant que maître. Peu de choses sont plus sujettes aux erreurs que la résolution de conflits de fusion.

• La fonctionnalité peut avoir subi plusieurs modifications et mises à jour depuis sa mise en œuvre d'origine, rendant la branche d'origine totalement obsolète. La seule façon de l'actualiser est de fusionner le maître dans la branche de fonctionnalités ... et à ce stade, vous ne faites que vous éloigner du maître d'une manière inutilement compliquée.

• Ne serait-ce que par souci de simplicité, il est généralement judicieux de disposer du même flux de travail pour les mises à jour, les corrections de bugs et les nouvelles fonctionnalités. Cela s'applique aux branches, aux révisions de code, à l'utilisation du système de suivi des bogues et à peu près tout le reste. De toute façon, la différence entre mettre à jour une fonctionnalité existante, ajouter une nouvelle fonctionnalité et corriger un bogue est souvent subjective.

Utilisez une nouvelle branche.

Pour nommer, vous pouvez envisager l’utilisation d’un format interne qui considère que this_work est une extension ou une modification de this_work.

Par exemple, vous pouvez nommer la deuxième branche

modeling-member--attributes

avec le - signalant que le nom à gauche est la branche d'origine

Nous abordons un problème assez similaire en utilisant les numéros de tickets Jira pour les noms de succursales. Parfois, il y a un peu de travail supplémentaire pour le même ticket. Parfois, une modification de base de données ne pouvait pas être annulée. Dans ces cas, nous utilisons, par exemple, la branche d'origine SEND-123 et la deuxième branche est SEND-123a

Si vous souhaitez enregistrer uniquement les validations issues d'une fusion sur le maître et que vous utilisez github, vous pouvez utiliser "Fourchette" pour chaque nouvelle fonctionnalité, effectuer une demande d'extraction et accepter la demande d'extraction après avoir effectué chaque nouvelle fonctionnalité.

Je ne recommande pas de travailler sur d'anciennes branches, car vous pouvez avoir des conflits lorsque vous le fusionnez avec le chef du maître et bien sûr, il n'est pas nécessaire de le faire ...