Quand supprimer des branches dans Git?

Supposons que nous ayons une application stable.

Demain, quelqu'un signale un gros bogue que nous décidons de corriger immédiatement. Nous créons donc une branche pour ce correctif hors de "master", nous l'appelons "2011_Hotfix", et nous le poussons pour que tous les développeurs puissent collaborer pour le corriger.

Nous corrigeons le bogue et fusionnons "2011_Hotfix" dans "master" ainsi que dans la branche de développement actuelle. Et appuyez sur "maître".

Que faisons-nous avec "2011_Hotfix" maintenant? Doit-elle simplement rester là comme une branche pour toujours jusqu'à la fin des temps ou devrions-nous maintenant la supprimer, car elle a atteint son objectif? Il semble impur de laisser des branches traîner partout, car la liste des branches deviendra probablement très longue, la plupart n'étant même plus nécessaires.

En cas de suppression, que va-t-il advenir de son histoire? Cela sera-t-il maintenu, même si la succursale actuelle n'est plus disponible? De plus, comment 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 (c'est-à-dire que vous perdriez les validations en supprimant la branche), git vous le dira et ne le supprimera pas.

Ainsi, la suppression d'une branche fusionnée est bon marché et ne vous fera perdre aucun historique.

Pour supprimer une branche distante, utilisez git push origin :mybranch, en supposant que votre nom distant est origine et que la branche distante que vous souhaitez supprimer s'appelle mybranch.

Ce que vous devez faire, c'est étiqueter tout ce que vous publiez. Gardez les succursales 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 pousser dans branch_name à l'origine".

Cela dit, tant que le DAG (graphique acyclique dirigé) peut le pointer, les commits seront là dans l'histoire.

Google "git-flow" et qui peut donner plus d'informations sur la gestion des versions, les branchements et le balisage.

Étant donné que la question a la balise "github", j'ajouterais également ceci: spécifiquement dans Github , si vous tirez-demandez une branche et qu'elle est fusionnée (soit via l'interface utilisateur, soit en fusionnant la branche de la demande de tirage), vous ne le ferez pas perdez les données de la demande d'extraction (y compris les commentaires), même si vous supprimez la branche .

Conséquence de ceci: si vous intégrez des demandes d'extraction dans le cadre de votre flux de travail (qui se fond harmonieusement avec les révisions de code), vous pouvez supprimer en toute sécurité les branches dès qu'elles sont fusionnées. C'est tellement banal que Github a récemment ajouté une fonctionnalité (douce) qui fait apparaître un bouton "supprimer la branche" juste après avoir fusionné une demande d'extraction.

Mais il convient de noter que chaque groupe doit adopter le flux de travail qui lui convient le mieux (et qu'il peut ou non entraîner la suppression de ces branches). Mon équipe de travail actuelle, par exemple, élague toutes les branches qui ne sont pas liées au maître ou au déploiement (par exemple, la production, le transfert, etc.) dès que leurs demandes d'extraction sont fusionnées, et nous avons toujours un suivi complet de la façon dont les validations associées se sont formées. chaque amélioration incrémentale de chaque produit.

Bien sûr, aucune gestion d'historique (pull requêtes ou autre) ne remplace le balisage approprié des versions (que vous automatisez de préférence avec le même outil / script qui déploie / empaquette une version), vous pouvez donc toujours passer rapidement à ce que vos utilisateurs se trouvent sur à un moment donné. Le balisage est également la clé pour résoudre votre problème d'origine: si vous établissez que toute branche fusionnée aux branches "travail" peut et doit être supprimée, et que toute fusion à une balise de version, "production", etc. ne doit 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 supprimer des branches est que vous casserez tous les hyperliens vers ces branches sur GitHub (cette question est étiquetée github). Vous obtiendrez une 404 Not Founderreur 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 e-mails, j'évite désormais les hyperliens vers les branches GitHub et je crée un lien vers une validation ou une balise dès le 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.

Je supprime d'abord ma succursale locale. Cela l'empêche d'être poussé accidentellement plus tard.

git branch -d branchName

Ensuite, 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 généralement conserver les commits pour la postérité. Cependant, j'aime toujours supprimer la branche. Pour répartir les commits et les empêcher d'être mangés par le garbage collector, je crée une balise annotée pointant vers le même commit que la branche supprimée.

git tag -a tagName commitOrBranchName

Ensuite, je pousse la balise sur github

git push remoteName tagName

Il semble que vous souhaitiez supprimer la 2011_Hotfixbranche sans perdre son historique. Je vais discuter de la suppression en premier et de l'histoire en second.

Les gitméthodes de suppression de branche habituelles ont déjà été décrites ci-dessus et fonctionnent comme prévu. gitn'a pas de commande à un ou deux mots qui signifie «Hé git, supprimez la branche 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 $PATHrépertoires. Si vous n'êtes pas sur la 2011_Hotfixbranche, vous exécutez simplement git-nuke 2011_Hotfixsupprimera les branches locales et distantes. C'est beaucoup plus rapide et plus simple - bien que peut-être plus dangereux - que les gitcommandes standard .

Votre souci de préserver l'histoire est bon. Dans ce cas, ne vous inquiétez pas. Une fois que vous fusionnez 2011_Hotfixsur master, tous les commits de 2011_Hotfixseront ajoutés à masterl » historique des commits. En bref, vous ne perdrez pas l'historique 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 ait 20 minuscules "travaux en cours" engagés 2011_Hotfix; cependant, vous ne souhaitez 2011_Hotfixajouter qu'un seul commit complet à masterl'historique de. Comment combinez-vous les 20 petits commits en un seul gros commit? Heureusement, gitvous permet de consolider plusieurs validations en une seule validation à l'aide de git-rebase. Je ne vais pas expliquer ici comment cela fonctionne; cependant, si vous êtes intéressé, la documentation degit-rebase est excellente. Notez que git rebaseréécrit l'histoire, il doit donc être utilisé judicieusement, surtout si vous êtes nouveau. Enfin, votre 2011_Hotfixscénario concerne une équipe de développeurs, pas un développeur solo. Si les membres de l'équipe de projet utilisentgit rebase, il est judicieux pour l'équipe d'avoir des directives explicites sur l'utilisation de git rebaseafin qu'un développeur de cow-boy de l'équipe n'endommage pas involontairement l' githistorique d' un projet .

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 le faire en toute sécurité git branch -d branchname.

Si vous souhaitez tailler les branches locales qui ont été supprimées de l'origine, vous pouvez également tailler, tout en utilisant git fetch

git fetch --prune

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