Quel est le bon moment pour supprimer une branche de fonctionnalité git?

88

Je ne veux pas me retrouver avec 82 branches de fonctionnalités qui traînent , alors je me demande quels sont les inconvénients potentiels à simplement supprimer la branche de fonctionnalité dès que je la fusionne avec master.

Flux de travail:

git co -b feat-xyz
hack hack
git ci
hack some more
git ci
git co master
git merge feat-xyz
smoke test
git br -d feat-xyz

Des problèmes ici?

git version-control branch

— Bstpierre
source

1

Je dirais pas de problème car si vous en avez vraiment besoin, vous pouvez toujours ressusciter la branche supprimée plus tard.

— slebetman

@slebetman Autant que je sache, une branche supprimée ne peut pas être ressuscitée. Cependant, si la branche a été entièrement fusionnée dans master avant de la supprimer, la branche ne devrait plus être nécessaire.

— Simeon

1

@Simeon Oui, vous pouvez. Git ne supprime jamais les commits, donc lorsque vous supprimez votre branche, vous supprimez simplement son nom. Pour ressusciter une branche supprimée, vous devez simplement vous souvenir de la dernière chose que vous avez engagée dans cette branche et vous pouvez la rechercher git reflog. Ensuite

— vérifiez

@slebetman qui ne sera vrai que si la branche a finalement été fusionnée. si les commits sont laissés pour compte, ils finiront par devenir inaccessibles et seront soumis au ramasse-miettes après un certain temps. même les entrées dans le reflog seront éventuellement purgées, vous avez environ 90 jours par défaut.

— goldenratio

@goldenratio: Une référence à ce sujet?

— slebetman

61

Supprimer après la fusion est la méthode habituelle. C'est pourquoi il git branch -d yourbranchnamevérifie que la branche est complètement fusionnée avant qu'elle ne soit supprimée.

Il y a plusieurs raisons auxquelles je peux penser pour garder une branche: vous voudrez peut-être la conserver au cas où vous auriez des bogues qui reviendraient une fois qu'elle sera en production, ou vous voudrez peut-être un enregistrement historique.

Dans les deux cas, vous avez la possibilité de baliser la tête de la branche avant de la supprimer. Une balise est comme une branche en ce qu'elle est un pointeur vers un commit, à l'exception de quelques différences mineures: 1) porcelain n'affiche généralement pas les balises dans les commandes exploratoires telles que git show-branch ou tab-auto complete lors du paiement, 2) en vérifier un vous place dans une HEAD détachée (non-ref) 3) vous pouvez laisser un " message de balisage ", ce qui entraîne l'enregistrement de la balise en tant qu'objet dans le magasin d'objets comme un commit.

De cette façon, vous préservez l'historique, et si jamais vous avez besoin de corriger un bogue, je vous recommande simplement de créer une nouvelle branche hors de master pour le correctif.

— maçon
source

1

La vérification d'une balise définit HEAD, mais ne crée pas automatiquement une branche. Un HEAD sur un commit sans branche est ce qui le rend détaché.

— Binarian

1

Vous avez raison, il définit HEAD sur un identifiant de validation plutôt qu'une référence. Cette partie de mon OP est incorrecte. Je devrais le mettre à jour.

— masonk

96

Je supprime après la fusion, mais je fais toujours un git merge --no-ff, pour éviter une avance rapide afin que l'historique des branches soit visible sur le graphique. J'aime avoir l'historique de l'endroit où la branche de fonctionnalité est partie de la branche de développement et où elle est revenue:

Fusion avec ou sans avance rapide

Ceci est tiré d' un modèle de branchement Git réussi de Vincent Driessen, un flux de travail très agréable à utiliser avec git que j'applique pour la plupart de mes projets.

— lkraider
source

C'est une autre manière intéressante de préserver l'historique, car vous pouvez sélectionner les validations accessibles depuis la fonctionnalité mais pas depuis master: rev ^ 1..rev ^ 2. L'inconvénient est que cela gâche tout rebasage que vous voudrez peut-être faire à partir de votre branche maître (par exemple, si vous voulez garder le maître rebasé sur une télécommande en amont, ce qui est très courant).

— masonk

1

Je n'ai pas eu ce problème. Notre équipe se synchronise via github, et je n'ai généralement pas besoin de rebaser, mais je ne pense pas que ce soit un inconvénient ici. Même si vous rebasez votre branche de développement et de fonctionnalité, le branchement reste visible sur le graphique, et ce qui compte, c'est ce qui se trouve dans la branche de fonctionnalité par rapport au développement, et non le commit où vous vous êtes départi lorsque vous avez créé cette branche.

— lkraider

@Ikraider, merci pour le rappel. J'ai vu cet article quand j'ai appris git pour la première fois, cela a plus de sens pour moi maintenant. Je rebase mes branches de fonctionnalités, mais je merge --no-ffreviens sur master car, comme vous le dites, vous pouvez voir l'historique.

— bstpierre

7

Je peux penser à deux raisons pour lesquelles vous voudrez peut-être garder un peu une branche de fonctionnalité:

Il y a une chance qu'il vous soit renvoyé pour plus de travail en amont.
D'autres développeurs voudront peut-être cette fonctionnalité sans vouloir tout le reste dans master.

En pratique, la plupart du temps, la suppression après la fusion est très bien.

— Karl Bielefeldt
source

6

Le flux de travail typique sera

 // Create new branch
 $ git checkout -b myfeature
 // and then do some changes and commit them

 // Switch to master branch
 $ git checkout master

 // Merge myfeature to master. --no-ff will always keep branch information.
 $ git merge --no-ff myfeature

 // Delete myfeature branch
 $ git branch -d myfeature

 // Push the changes
 $ git push origin master

— Fizer Khan
source

1

je pense que c'est le flux de travail typique (suppression après fusion)

EDIT Donc, plutôt que de fusionner, au moins pour les branches de courte durée, je pense que l'idée est de les rebaser sur le maître. alors vous vous retrouvez avec un historique de changement linéaire, et la branche entière devient une partie du tronc principal. dans ce cas, vous avez tous les changements là-bas donc vous n'avez clairement pas besoin d'une copie.

— seconde
source

Il n'y a donc vraiment aucun intérêt à garder la succursale, non?

— bstpierre

1

Je recommande fortement d'éviter le "rebase". Le rebasage est généralement nocif, utile seulement dans certains cas.

— Dietrich Epp

9

Le rebasage est un flux de travail parfaitement raisonnable pour vos succursales privées locales. Il est très courant de rester synchronisé avec le travail en amont en rebasant par exemple ("rebasing down "). Il est beaucoup moins courant et généralement nuisible de rebaser *. La réponse de second n'a pas vraiment de sens, car que vous rebasiez ou fusionniez dans des changements en amont, vous devez toujours pousser ces choses "vers le haut" d'une manière ou d'une autre. Même sur votre succursale locale, vous devrez fusionner votre fonctionnalité pour la maîtriser à un moment donné. L'avantage de rester rebasé sur vos fonctionnalités est que cette fusion avance rapidement.

— masonk

1

Il y a cependant quelque chose à surveiller avec le rebasage des branches, ce qui m'a mordu récemment. C'est évident maintenant, mais je suis allé pendant des mois sur une branche de longue durée, rebasant toujours le tout contre maître. Cela a abouti à environ 600 commits précis et granulaires, mais le master avait été complètement refacturé et complètement changé à plusieurs reprises. En rebasant la branche entière à chaque fois, je supprimais ses anciens commits de leur connexion aux commits maîtres qui avaient du sens pour eux. Maintenant, je préfère de loin fusionner dans master en cas de besoin. Je ne rebaserai que si l'historique de la branche ne sera absolument pas affecté.

— Gary Fixler