Quand supprimer des twigs dans Git?

Supposons que nous ayons une application stable.

Demain, quelqu’un rapporte un gros bogue que nous décidons de corriger immédiatement. Donc, nous créons une twig pour ce correctif 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 twig de développement en cours. Et poussez “maître”.

Que faisons-nous avec “2011_Hotfix” maintenant? Devrait-il restr une twig pour toujours jusqu’à la fin des temps ou devrions-nous maintenant la supprimer, car elle a atteint son objective? Il semble impur de ne laisser que des twigs partout, car la liste des twigs deviendra probablement très longue, la plupart ne sont même plus nécessaires.

Dans le cas où il devrait être supprimé, qu’adviendra-t-il de son histoire? Sera-t-il maintenu, même si la succursale actuelle n’est plus disponible? Comment puis-je supprimer une succursale distante?

Vous pouvez supprimer en toute sécurité une twig avec git branch -d yourbranch . Si elle contient des modifications non fusionnées (c.-à-d. Que vous perdriez les commits en supprimant la twig), git vous le dira et ne le supprimera pas.

Ainsi, supprimer une twig fusionnée est bon marché et ne vous fera perdre aucun historique.

Pour supprimer une twig distante, utilisez git push origin :mybranch , en supposant que votre nom distant est origine et que la twig distante que vous voulez supprimer est nommée mybranch.

Ce que vous devez faire, c’est étiqueter tout ce que vous libérez. Gardez les twigs autour de vous lorsque vous vous développez activement.

Supprimer les anciennes twigs 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 (graphe acyclique dirigé) peut le pointer, les commits seront présents dans l’histoire.

Google “git-flow” et cela peut donner plus de renseignements sur la gestion des versions, la création de succursales et le marquage.

Comme la question a la balise “github”, j’appendais aussi ceci: spécifiquement dans Github , si vous extrayez une twig et que celle-ci est fusionnée (via l’interface utilisateur ou en fusionnant la twig de la requête d’extraction), vous ne le ferez pas perdez les données de la requête d’extraction (y compris les commentaires), même si vous supprimez la twig .

Une conséquence de ceci: si vous incorporez des requêtes de type pull dans le cadre de votre workflow (qui s’intègre harmonieusement aux révisions de code), vous pouvez supprimer des twigs en toute sécurité dès qu’elles sont fusionnées. C’est tellement banal que récemment, Github a ajouté une fonctionnalité (douce) qui affiche un bouton “supprimer une twig” juste après avoir fusionné une requête d’extraction.

Toutefois, il convient de noter que chaque groupe doit adopter le stream de travail qui lui convient le mieux (et qu’il peut ou non conduire à la suppression de ces twigs). Mon équipe de travail actuelle, par exemple, élague toutes les twigs qui ne sont pas maîtres ou liées au déploiement (par exemple, production, transfert, etc.) dès que leurs requêtes d’extraction sont fusionnées chaque amélioration progressive de chaque produit.

Bien sûr, aucune gestion de l’historique (requêtes de tirage ou autres) ne remplace le balisage correct des versions (que vous automatiserez de préférence avec le même outil / script qui déploie / empaquette une version), vous pourrez donc toujours basculer rapidement sur vos utilisateurs. à un moment donné. Le balisage est également la clé pour résoudre votre problème d’origine: si vous établissez que n’importe quelle twig fusionnée aux twigs “work” peut et doit être supprimée, et que toute fusion avec une balise de version “production”, etc. , vous aurez toujours les correctifs en vie jusqu’à ce qu’ils soient intégrés dans une future version.

Je voudrais append que l’inconvénient de la suppression de twigs est que vous allez casser tous les liens hypertexte vers ces twigs sur GitHub (cette question est github balisé). Vous obtiendrez une erreur 404 Not Found pour ces liens. C’est pourquoi je change mes liens pour pointer vers un commit ou une balise après avoir supprimé une twig sur GitHub.

Comme certains liens ne peuvent pas être modifiés, comme dans le courrier électronique, j’évite maintenant de créer des liens hypertextes avec les twigs de GitHub et de créer un lien vers une validation ou une balise dès le premier jour.

Je préfère supprimer les twigs après leur fusion. Cela évite l’encombrement visuel d’une longue liste de twigs dans votre référentiel. Ces twigs sont également propagées à toutes les fourches du référentiel.

Je commence par supprimer ma twig locale. Cela l’empêche d’être accidentellement poussé plus tard.

 git branch -d branchName 

Puis je supprime la twig de suivi à distance

 git branch -dr remoteName\branchName 

Ensuite, je supprime la twig sur GitHub. J’utilise l’interface Web, mais la commande équivalente est ci-dessous.

 git push remoteName :branchName 

Même si la twig n’est jamais fusionnée, je voudrais généralement garder les engagements pour la postérité. Cependant, j’aime toujours supprimer la twig. Pour répartir les commits et les empêcher d’être consommés par le garbage collector, je crée une balise annotée qui pointe vers le même commit que la twig supprimée.

 git tag -a tagName commitOrBranchName 

Puis je pousse le tag à github

 git push remoteName tagName 

Il semble que vous souhaitiez supprimer la twig 2011_Hotfix sans perdre son historique. Je discuterai de la suppression en premier et de l’histoire en second.

Les méthodes habituelles de suppression des twigs git ont déjà été décrites ci-dessus et fonctionnent comme prévu. git ne possède pas de commande à un ou deux mots, ce qui signifie: “Hey git , supprimez à la fois la twig locale et la twig 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 ceci dans un fichier exécutable (par exemple, git-nuke ) dans l’un de vos répertoires $PATH . Si vous n’êtes pas sur la twig 2011_Hotfix , il vous suffit d’exécuter git-nuke 2011_Hotfix pour supprimer les twigs locales et distantes. C’est beaucoup plus rapide et plus simple – mais peut-être plus dangereux – que les commandes git standard.

Votre souci de préserver l’histoire est bon. Dans ce cas, vous ne devez pas être inquiet. Une fois que vous avez fusionné 2011_Hotfix sur master , tous les commits de 2011_Hotfix seront ajoutés à l’historique de validation de master . En bref, vous ne perdrez pas l’histoire d’une simple fusion.

J’ai encore un mot à append qui dépasse peut-être la scope de votre question, mais qui est néanmoins pertinent. Imaginons qu’il y ait 20 petits “travaux en cours” sur 2011_Hotfix ; Cependant, vous ne souhaitez append qu’un seul commit complet pour 2011_Hotfix à l’ 2011_Hotfix de master . Comment combinez-vous les 20 petits engagements en un seul grand engagement? Heureusement, git vous permet de consolider plusieurs commits en une seule fois en utilisant git-rebase . Je ne vais pas expliquer ici comment cela fonctionne; cependant, si cela vous intéresse, la documentation de git-rebase est excellente. Notez que git rebase réécrit l’historique, il convient donc de l’utiliser judicieusement, surtout si vous êtes nouveau. Enfin, votre scénario 2011_Hotfix concerne une équipe de développement, pas un développeur solo. Si les membres de l’équipe de projet utilisent git rebase , il est judicieux que l’équipe dispose de directives explicites sur l’utilisation de git rebase afin que certains développeurs de cow-boys n’endommagent pas involontairement l’historique de git un 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 en toute sécurité git branch -d branchname .

Vous pouvez supprimer des twigs dans toutes les principales interfaces utilisateur Web telles que github, BitBucket. Après avoir supprimé la twig en ligne, vous pouvez supprimer la twig locale en utilisant

 git remote prune origin