Quand supprimer des branches dans Git?
Supposons que nous ayons une application stable.
Demain, quelqu'un signale un gros problème que nous décidons de corriger immédiatement. Donc, nous créons une branche pour ce correctif à partir de "maître", nous l'appelons "2011_Hotfix", et nous la mettons en place afin que tous les développeurs puissent collaborer à sa correction.
Nous corrigeons le bogue et fusionnons "2011_Hotfix" dans "maître" ainsi que dans la branche de développement actuelle. Et Poussez "maître".
Que faisons-nous avec "2011_Hotfix" maintenant? Devrait-elle rester comme une branche pour toujours jusqu'à la fin des temps ou devrions-nous la supprimer maintenant, car elle a atteint son objectif? Il semble impur de laisser des branches qui traînent partout, car la liste des branches deviendra probablement très longue, dont la plupart ne sont même plus nécessaires.
Au cas où il devrait être supprimé, qu'adviendra-t-il de son histoire? Cela sera-t-il maintenu, même si la branche actuelle n'est plus disponible? Aussi, comment pourrais-je supprimer une branche distante?
Vous pouvez supprimer en toute sécurité une branche avec git branch -d yourbranch. S'il contient des modifications non fusionnées (par exemple, vous perdriez des validations en supprimant la branche), git vous le dira et ne le supprimera pas.
Donc, supprimer une branche fusionnée est peu coûteux et ne vous fera perdre aucun historique.
Pour supprimer une branche distante, utilisez git Push Origin :mybranch, en supposant que votre nom distant est Origin et que la branche distante que vous souhaitez supprimer s'appelle mybranch.
Ce que vous devez faire, c'est marquer tout ce que vous libérez. Gardez les branches autour lorsque vous vous développez activement.
Supprimer 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 "Ne rien mettre dans branch_name at Origin".
Cela dit, tant que le graphe acyclique dirigé peut y pointer, les commits seront là dans l’histoire.
Google "git-flow" et cela peut donner plus d'informations sur la gestion des versions, la création de branches et le marquage.
Etant donné que la question a la balise "github", je voudrais aussi ajouter ceci: spécifiquement dans Github , si vous pull-request une branche et qu'elle est fusionnée (soit via l'interface utilisateur, soit en fusionnant l'extraction request), vous ne perdrez pas les données de la demande d'extraction (y compris les commentaires), même si vous supprimez la branche.
Conséquence: si vous intégrez des demandes d'extraction à votre flux de travail (ce qui se combine parfaitement avec les révisions de code), vous pouvez supprimer des branches en toute sécurité dès leur fusion. Ceci est si banal que Github a récemment ajouté une fonctionnalité (attrayante) qui ouvre un bouton "Supprimer une branche" juste après la fusion d'une demande d'extraction.
Mais il convient de noter que chaque groupe doit adopter le flux de travail qui lui convient le mieux (et cela peut éventuellement conduire à la suppression de telles branches). Mon équipe de travail actuelle, par exemple, élague toutes les branches qui ne sont pas liées au déploiement ou au maître (par exemple, la production, la mise en scène, etc.) dès que leurs demandes d'extraction sont fusionnées, et nous avons toujours un suivi complet de la manière dont les commits liés sont formés chaque amélioration progressive de chaque produit.
Bien sûr, aucune gestion de l'historique (demandes d'extraction ou autres) ne remplace le balisage correct des versions (que vous automatisez de préférence avec le même outil/script qui déploie/compile une version), de sorte que vous pouvez toujours basculer rapidement vers le contenu de vos utilisateurs. à un moment donné. Le balisage est également la solution pour résoudre votre problème initial: si vous établissez que toute branche fusionnée avec les branches "travail" peut et doit être supprimée, et que toute branche fusionnée avec une balise de version, "production", etc. ne devrait pas , vous aurez toujours les correctifs en vie jusqu’à ce qu’ils soient intégrés dans une future version.
J'ajouterais que l'inconvénient de la suppression de branches est que vous supprimerez les hyperliens vers ces branches sur GitHub (cette question est étiquetée github). Vous obtiendrez une erreur 404 Not Found pour ces liens. C'est pourquoi je modifie mes liens pour qu'ils pointent sur une validation ou une balise après avoir supprimé une branche sur GitHub.
Certains liens ne pouvant pas être modifiés, par exemple dans les e-mails, j’évite maintenant les hyperliens vers les branches de GitHub et les liens vers un commit ou une balise du premier jour.
Je préfère supprimer les branches après leur fusion. Cela évite l'encombrement visuel d'une longue liste de branches dans votre référentiel. Ces branches sont également propagées à toutes les fourches du référentiel.
D'abord je supprime ma branche locale. Cela l'empêche d'être accidentellement poussé plus tard.
git branch -d branchName
Puis je supprime la branche de suivi à distance
git branch -dr remoteName\branchName
Ensuite, 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, j’aimerais toujours garder les commits pour la postérité. Cependant, j'aime toujours supprimer la branche. Pour écarter les commits et les empêcher d'être mangés par le ramasse-miettes, je crée une balise annotée pointant sur le même commit que la branche supprimée.
git tag -a tagName commitOrBranchName
Puis je pousse le tag vers github
git Push remoteName tagName
Il semble que vous souhaitiez supprimer la branche 2011_Hotfix sans perdre son historique. Je vais discuter de la suppression d'abord et de l'histoire ensuite.
Les méthodes habituelles de suppression de branches git ont déjà été décrites ci-dessus et fonctionnent comme prévu. git n'a pas une ou deux commandes Word qui signifie "Hey git, supprime les branches locale et distante." Mais ce comportement peut être imité via un script shell. Par exemple, prenez le script Shell de Zach Holman 'git-nuke' . C'est très simple:
#!/bin/sh
git branch -D $1
git Push Origin :$1
Placez-le dans un fichier exécutable (par exemple, git-nuke) dans l’un de vos répertoires $PATH. Si vous n'êtes pas sur la branche 2011_Hotfix, il vous suffira d'exécuter git-nuke 2011_Hotfix pour supprimer les branches locales et distantes. C’est beaucoup plus rapide et plus simple - bien que peut-être plus dangereux - que les commandes git standard.
Votre souci de préserver l’histoire est bon. Dans ce cas, vous n'avez pas besoin de vous inquiéter. Une fois que vous avez fusionné 2011_Hotfix avec master, tous les commits de 2011_Hotfix seront ajoutés à l'historique de commit de master. En bref, vous ne perdrez pas l’histoire d’une simple fusion.
J'ai encore un mot à ajouter qui dépasse peut-être la portée de votre question, mais qui est néanmoins pertinent. Imaginons qu'il y a 20 minuscules "travaux en cours" validés sur 2011_Hotfix; Cependant, vous souhaitez qu'un seul commit complet pour 2011_Hotfix soit ajouté à l'historique master. Comment combinez-vous tous les 20 petits commits en un seul grand commet? Heureusement, git vous permet de consolider plusieurs commits en un seul en utilisant git-rebase. Je ne vais pas expliquer ici comment cela fonctionne. cependant, si cela vous intéresse, la documentation pour git-rebase est excellente. Notez que git rebase réécrit l’historique, il devrait donc être utilisé judicieusement, surtout si vous êtes nouveau. Enfin, votre scénario 2011_Hotfix concerne une équipe de développement, pas un développeur en solo. Si les membres de l'équipe de projet utilisent git rebase, il est conseillé à l'équipe de disposer de directives explicites sur l'utilisation de git rebase afin que certains développeurs cowboy de l'équipe n'endommagent pas involontairement l'historique git du projet.
Si elle a été fusionnée avec succès et peut-être même étiquetée, je dirais qu'elle ne sert plus à rien. Vous pouvez donc faire git branch -d branchname en toute sécurité.
Vous pouvez supprimer des branches dans toutes les principales interfaces utilisateur Web telles que github, BitBucket. Après avoir supprimé la branche en ligne, vous pouvez supprimer la branche locale à l'aide de
git remote Prune Origin
Si vous souhaitez supprimer les branches locales supprimées d’Origin, vous pouvez également procéder à la suppression, tout en utilisant git fetch.
git fetch --Prune