Quel est le bon moment pour supprimer une branche de Git?

Question

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 de la suppression de la branche de caractéristiques dès que je la fusionne pour la maîtriser.

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?

Answer 1

J'ai supprimer après la fusion, mais je fais toujours un git merge --no-ff, pour éviter le transfert rapide de sorte que l'histoire de la branche est visible sur le graphique. J'aime avoir l'histoire de l'endroit où la branche s'écarte de la direction du développement et où il rejoint dos:

Ceci est pris à partir d' Un succès Git ramification modèle par Vincent Driessen, un très bon flux de travail à utiliser avec git que j'applique pour la plupart de mes projets.

Answer 2

Supprimer après la fusion est la manière habituelle. C'est pourquoi git branch-d vérifications pour s'assurer que la direction est complètement fusionné avant de les supprimer.

Il ya quelques raisons qui, je pense, de garder une branche autour de vous: vous pourriez vouloir le retenir dans le cas où vous avez des punaises de revenir une fois qu'il frappe de la production, ou vous voudrez peut-être un record historique.

Dans les deux cas, vous avez l'option de marquage de la tête de la branche avant de le supprimer. Un tag, c'est comme une branche en ce qu'il est un pointeur vers un commit, à l'exception de quelques différences mineures: 1) la porcelaine n'a généralement pas d'affichage des balises dans exploratoire des commandes comme git show-branche ou de l'onglet-automatique dans la caisse, 2) la vérification de l'un n'affecte pas la TÊTE (vous serez dans un décollement de la TÊTE), et 3) vous pouvez laisser un "tag" note sur le dessus de la note sur la commettre que des points.

De cette façon, vous préserver de l'histoire, et si jamais vous avez besoin de correction de bug, je recommande simplement la création d'une nouvelle branche de maître pour la correction.

Answer 3

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

Answer 4

Je pense à deux raisons pour lesquelles vous voudrez peut-être garder une branche autour pour un peu:

• Il y a une chance qu'il aura des coups de pied de retour pour plus de travail en amont.
• D'autres développeurs, éventuellement, voulant que, sans vouloir tout le reste en maître.

Dans la pratique, la plupart du temps la suppression d'après la fusion est tout simplement parfait.

Answer 5

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

MODIFIER Donc, plutôt que de fusionner, au moins pour une courte durée en branches, je pense que l'idée est de rebase sur le maître. puis vous vous retrouvez avec une variation linéaire de l'histoire, et l'ensemble de la branche devient une partie du tronc principal. dans ce cas, vous disposez de tous les changements, il n'y donc, de toute évidence, vous n'avez pas besoin d'une copie.