Pourquoi devrais-je utiliser des balises par rapport aux branches release / beta pour le contrôle de version?

114

J'utilise git depuis environ un an et j'aimerais utiliser le balisage pour marquer les commits dans différentes versions. J'ai trouvé beaucoup d'informations sur les commandes à utiliser pour travailler avec les balises, mais ce que j'aimerais savoir, c'est pourquoi utiliser le balisage si je peux simplement créer une nouvelle branche appelée 1.1.0et ne pas avoir à obscurcir mon esprit avec un tout nouvel ensemble de commandes git?

Il doit y avoir beaucoup de bonnes raisons de baliser plutôt que de créer des branches, mais j'aimerais savoir quels sont ces avantages.

git branch git-tag

— wufoo
source

96

Les balises sont principalement utilisées pour référence future à la version spécifique du projet, en balisant un commit. Vous pouvez toujours utiliser des branches bien sûr, mais si vous changez beaucoup de versions, vous vous retrouverez avec beaucoup de branches inutilisées ou rarement utilisées.

En pratique, les balises sont de toute façon des branches sans branches, ajoutant simplement un moyen de référencer une version spécifique du projet pour réduire la complexité.

Edit: Voici une belle façon d'utiliser git que j'utilise pour tous mes projets.

— Hakan Deryal
source

Heh (: C'est vraiment un excellent flux de travail qui couvre toutes les solutions possibles.

— Hakan Deryal

oui, j'ai déjà vu la méthode nvie et j'en ai été assez perplexe. Néanmoins, j'aspire à le mettre en œuvre une fois que je l'ai compris. Je suppose qu'avec une balise, vous ne pouvez pas modifier accidentellement le code, commettre et être toujours à la même version. Avec les branches, cela peut arriver par inadvertance. Les balises semblent être un moyen plus sûr de marquer les communiqués.

— wufoo

2

La beauté de la méthode nvie pour moi était que je n'avais pas besoin de la comprendre au départ. Je pourrais simplement trouver la section pour ce que je voulais faire et taper les commandes. Après quelques fois, c'est devenu naturel et en quelques jours, je dansais autour des branches comme un pro!

— Killroy

Espérer comprendre l'approche gitflow en l'appliquant simplement aveuglément vous fera manquer toutes les simplifications que vous pourriez lui appliquer pour votre situation. Et gitflow est en effet inapproprié pour la plupart des équipes: soit trop complexe, soit trop simple.

— toolforger

151

Une balise est immuable .

Alors que vous pouvez créer une branche nommée "1.0.0" - vous, ou toute personne ayant des droits de validation, pouvez également simplement pousser vers cette branche (délibérément ou non) et changer ce que signifie 1.0.0.

Vous ne pouvez pas faire cela avec une balise, une fois que vous créez une balise - c'est tout; La balise 1.0.0 signifie exactement cela et ne peut pas être modifiée ^* .

C'est la principale différence pratique entre une étiquette et une branche

^* Vous pouvez supprimer et recréer une balise modifiant ainsi une balise, mais certainement pas par accident.

— AD7six
source

18

J'ai tendance à utiliser un flux de travail qui intègre à la fois des balises et des branches. Les balises sont utiles pour marquer le code publié ou les versions de développement notables. Les branches sont utiles pour garder une trace de toutes les modifications pertinentes pour une version spécifique.

Voici un bon article sur ce type de flux de travail: http://nvie.com/posts/a-successful-git-branching-model/

— Justin ᚅᚔᚈᚄᚒᚔ
source

18

La branche et le tag sont la même chose (pointeur vers un commit, aka. "Ref" ), sauf que la branche se déplace automatiquement vers le prochain commit tandis que le tag reste pour toujours ¹ sur le même commit.

Lors de la création d'une version, vous voulez généralement marquer le "snapshot" du code à partir duquel cette version a été construite, et vous voulez qu'elle reste marquée de cette façon même si vous continuez à faire évoluer le code, vous utiliseriez donc une balise.

Si vous avez essayé d'utiliser une branche pour cela, elle pourrait passer par inadvertance à un autre commit, à partir duquel la version n'a pas été construite.

¹ Sauf si vous supprimez le tag, bien sûr.

REMARQUE: Je me rends compte que c'est une vieille question, mais j'ai senti que la similitude (et une différence cruciale) entre les branches et les balises n'a pas été étoffée dans d'autres réponses aussi clairement qu'elle aurait pu l'être.

— Branko Dimitrijevic
source

Cher @downvoter, une raison spécifique pour le vote défavorable?

— Branko Dimitrijevic

Je n'ai pas décliné votre réponse, mais qu'entendez-vous par «la branche passe automatiquement au prochain commit»? Les branches ne se déplacent automatiquement vers aucun commit. L'exécution git commitmet à jour la tête de la branche extraite pour référencer le nouveau commit, oui, mais aucune autre branche ne se déplace «automatiquement» vers le prochain commit. Vous devriez clarifier le premier paragraphe de votre réponse.

— Brosse à dents

1

@Toothbrush Bien sûr, c'est ce que je voulais dire par «se déplace automatiquement». Cependant, la branche ne "possède" pas vraiment de commits, elle ne pointe même pas vers un ensemble de commits, elle pointe juste vers un commit (et le reste peut être impliqué, parfois de manière imprécise, en parcourant le graphe de commit). Sous git, branch est juste un fichier d'une ligne sous .git\refs\heads, contenant le hachage du commit. Les commits eux-mêmes ne "se souviennent" pas de la branche qui les a créés. Ceci est différent de Mercurial, par exemple, où les informations de la branche peuvent être écrites dans les métadonnées du commit.

— Branko Dimitrijevic

Oui, mais beaucoup de gens ne le savent pas - en particulier les nouveaux arrivants qui sont confus au sujet de la myriade de façons qui sont suggérées en ligne pour faire des choses avec Git.

— Brosse à dents

6

Vous utilisez des balises pour noter les commits importants dans l'historique. "C'était le commit exact que nous avons utilisé pour cette version ce jeudi pluvieux quand le serveur de build est tombé en panne". Si vous utilisez une branche au lieu d'une balise, vous ne pouvez jamais savoir quel commit exact vous avez utilisé. Vous ne savez que "Nous avons publié la version 1.1.0 quelque part sur cette branche", à moins que vous n'écriviez manuellement le hachage exact pour ce commit, c'est pourquoi vous utilisez des balises en premier lieu :)

— ralphtheninja
source

4

Je pense qu'il voulait dire créer une branche nommée 1.1.0 et ne plus l'utiliser, donc cela représentera le projet dans la version nommée.

— Hakan Deryal

2

En plus des autres réponses, voici mes 2 cents.

Réponse courte: utiliser des balises pour les versions de publication

Réponse longue: Je pense que l'utilisation de balises pour la gestion des versions de version est spécifiquement meilleure que l'utilisation de branches. Si vous avez besoin de mettre à jour la relase, branchez simplement le commit balisé et une fois que vous avez fini de travailler sur cette branche (probablement une branche de correctif), créez une nouvelle balise en tête de cette nouvelle branche avec la nouvelle version. Ensuite, fusionnez cette branche dans master / develop car vous ne devriez vraiment pas changer une version finale à moins qu'il ne s'agisse d'un correctif qui devrait probablement être fusionné dans votre code source. Supprimez ensuite cette branche car elle n'est plus nécessaire. Si vous devez appliquer un autre correctif à cette nouvelle version, répétez les mêmes étapes.

Reportez-vous à la section de l'article suivant qui montre comment fusionner un correctif avec le flux de travail Git de l'auteur - https://hackernoon.com/a-branching-and-releasing-strategy-that-fits-github-flow-be1b6c48eca2

— Région39
source