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
la source
la source
git reflog. EnsuiteRéponses:
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.
la source
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: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.
la source
merge --no-ffreviens sur master car, comme vous le dites, vous pouvez voir l'historique.Je peux penser à deux raisons pour lesquelles vous voudrez peut-être garder un peu une branche de fonctionnalité:
En pratique, la plupart du temps, la suppression après la fusion est très bien.
la source
Le flux de travail typique sera
la source
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.
la source