Quand supprimer des branches dans Git ?

Question

Supposons que nous ayons une application qui soit stable.

Demain, quelqu'un signalera un gros bogue que nous déciderons de corriger immédiatement. Nous créons donc une branche pour ce correctif à partir de "master", nous la nommons "2011_Hotfix", et nous la poussons vers le haut afin que tous les développeurs puissent collaborer à sa correction.

Nous corrigeons le bogue et fusionnons "2011_Hotfix" dans "master" ainsi que dans la branche de développement actuelle. Et nous poussons "master".

Que faisons-nous de "2011_Hotfix" maintenant ? Devrait-elle rester là comme une branche pour toujours jusqu'à la fin des temps ou devrions-nous la supprimer maintenant, puisqu'elle a rempli son rôle ? Il semble impur de laisser traîner des branches partout, car la liste des branches va probablement devenir très longue, la plupart d'entre elles n'étant même plus nécessaires.

Dans le cas où il serait supprimé, qu'adviendrait-il de son histoire ? Sera-t-il maintenu, même si la branche actuelle n'est plus disponible ? De même, comment supprimer une branche distante ?

Answer 1

Vous pouvez supprimer une branche en toute sécurité avec git branch -d yourbranch . Si elle contient des changements non fusionnés (c'est-à-dire que vous perdriez des commits en supprimant la branche), git vous le dira et ne la supprimera pas.

Ainsi, la suppression d'une branche fusionnée est peu coûteuse et ne vous fera pas perdre d'historique.

Pour supprimer une branche distante, utilisez git push origin :mybranch en supposant que le nom de la branche distante est origin et que la branche distante que vous voulez supprimer s'appelle mybranch.

Answer 2

Ce que vous devez faire, c'est marquer tout ce que vous publiez. Gardez des branches pour les moments où vous développez activement.

Supprimez les anciennes branches avec

git branch -d branch_name

Supprimez-les du serveur avec

git push origin --delete branch_name

ou l'ancienne syntaxe

git push origin :branch_name

qui se lit comme suit : "ne rien pousser dans nom_branche à l'origine".

Cela dit, tant que le DAG (directed acyclic graph) peut pointer vers lui, les commits seront présents dans l'historique.

Recherchez "git-flow" sur Google et vous obtiendrez peut-être plus d'informations sur la gestion des versions, le branchement et le balisage.

Answer 3

Puisque la question comporte l'étiquette "github", j'ajouterais aussi ceci : spécifiquement dans Github si vous demande de tirage au sort une branche et qu'elle est fusionnée (soit via l'interface utilisateur, soit en fusionnant la branche de la demande de retrait), vous ne perdrez pas les données de la demande de retrait (y compris les commentaires), même si vous supprimez la branche .

Une conséquence de ceci : Si vous intégrez les demandes de retrait dans votre flux de travail (ce qui se marie parfaitement avec les revues de code), vous pouvez supprimer sans risque les branches dès qu'elles sont fusionnées. C'est tellement courant que Github a récemment ajouté une fonctionnalité (sympathique) qui fait apparaître un bouton "supprimer la branche" juste après avoir fusionné une demande de retrait.

Mais il convient de noter que chaque groupe doit adopter le flux de travail qui lui convient le mieux (et qui peut ou non conduire à la suppression de ces branches). Mon équipe de travail actuelle, par exemple, supprime toutes les branches qui ne sont pas maîtresses ou liées au déploiement (par exemple, production, staging, etc.) dès que leurs demandes de pull sont fusionnées, et nous avons toujours un suivi complet de la façon dont les commits liés ont formé chaque amélioration incrémentale de chaque produit.

Bien sûr, aucune gestion de l'historique (demandes de pull ou autre) ne remplace un étiquetage approprié des versions (que vous automatisez de préférence avec le même outil/script qui déploie/empaquète une version), de sorte que vous pouvez toujours passer rapidement à ce que vos utilisateurs utilisent à un moment donné. Le balisage est également la clé pour résoudre votre problème initial : si vous établissez que toute branche fusionnée aux branches "travail" peut et doit être supprimée, et que toute branche fusionnée à un tag de version, "production", etc. ne doit pas l'être, vous aurez toujours les correctifs vivants jusqu'à ce qu'ils soient intégrés dans une version future.

Answer 4

J'ajouterais que l'inconvénient de la suppression des branches est que vous briserez tous les hyperliens vers ces branches sur GitHub (cette question est taguée github). Vous obtiendrez un 404 Not Found erreur pour ces liens. C'est pourquoi je change mes liens pour pointer vers un commit ou un tag après avoir supprimé une branche sur GitHub.

Étant donné que certains liens ne peuvent pas être modifiés, comme dans les courriers électroniques, j'évite désormais de créer des hyperliens vers les branches GitHub et je crée un lien vers un commit ou un tag dès le premier jour.

Je préfère supprimer les branches après qu'elles aient été fusionnées. Cela évite l'encombrement visuel d'une longue liste de branches dans votre référentiel. Ces branches sont également propagées à toutes les bifurcations du référentiel.

D'abord je supprime ma branche locale. Cela évite qu'elle soit accidentellement poussée plus tard.

git branch -d branchName

Ensuite, je supprime la branche de suivi à distance

git branch -dr remoteName\branchName

Puis je supprime la branche sur GitHub. J'utilise l'interface web, mais la commande équivalente est ci-dessous.

git push remoteName :branchName

Même si la branche n'est jamais fusionnée, je souhaite généralement conserver les commits pour la postérité. Cependant, j'aime toujours supprimer la branche. Pour répartir les commits et éviter qu'ils ne soient mangés par le ramasseur d'ordures, je crée un tag annoté pointant vers le même commit que la branche supprimée.

git tag -a tagName commitOrBranchName

Puis je pousse le tag sur github

git push remoteName tagName

Answer 5

Si elle a été fusionnée avec succès et peut-être même étiquetée, je dirais qu'elle n'a plus d'utilité. Vous pouvez donc en toute sécurité faire git branch -d branchname .