Configurer des étiquettes dans GitHub pour organiser les dépôts

  • 3 minutes

Les balises dans les référentiels GitHub sont des marqueurs désignant des moments spécifiques de l’historique d’un projet, tels que les versions de mise en production ou les validations désignées. En affectant des balises à des validations ou à des mises en production, les développeurs peuvent créer une chronologie structurée du développement de leur projet, ce qui facilite le suivi et la référence des jalons importants du cycle de vie des logiciels.

Planification

Pour tirer pleinement parti des balises dans les référentiels GitHub pour organiser votre codebase (ce qui faciliter la navigation et la compréhension), tenez compte des considérations suivantes lors de la planification de leur implémentation.

Versions de lancement

Balisez des validations ou des mises en production spécifiques en tant que versions. Suivez la notation sémantique de contrôle de version, largement acceptée comme standard de facto pour l’étiquetage des versions logicielles. Une utilisation courante consiste à préfixer vos noms de version avec la lettre « v » (par exemple, v1.0.0 ou v2.3.4). Si la balise n’est pas destinée à une utilisation en production, ajoutez une version préliminaire après le nom de la version (par exemple, v0.2.0-alpha ou v5.9-beta.3). Cela permet aux utilisateurs et aux collaborateurs de distinguer facilement les versions stables et les fonctionnalités encore en phase de test.

Mise en production de fonctionnalités

Balisez des validations ou des fusions qui présentent de nouvelles fonctionnalités ou des modifications importantes apportées au codebase. Utilisez des balises descriptives telles que « feature/new-login-page » ou « feature/payment-integration » pour mettre en évidence des versions spécifiques des fonctionnalités. Ces balises fournissent un historique clair des ajouts de fonctionnalités et permettent de suivre la progression des fonctionnalités individuelles au fil du temps.

Résolution des bogues

Validations ou fusions de balises qui résolvent les correctifs de bogues ou les problèmes signalés par les utilisateurs ou les collaborateurs. Utilisez des balises telles que bugfix/issue123 » ou « fix/critical-bug » pour indiquer les versions des correctifs de bogues. Les balises de correctifs de bogues facilitent l’identification des validations qui résolvent des problèmes spécifiques et garantissent que les correctifs sont appliqués de manière cohérente entre différentes versions du projet.

Versions de maintenance

Validations ou fusions de balises qui impliquent des tâches de maintenance telles que la refactorisation du code, les mises à jour de la documentation ou les mises à niveau des dépendances. Utilisez des balises telles que « maintenance/refactorisation de code » ou « update/documentation » pour marquer les versions de maintenance. Les balises de mise en production de maintenance permettent de suivre les modifications liées à la maintenance du code et de s’assurer que les mises à jour nécessaires sont documentées et appliquées correctement.

Étiquettes personnalisées

Créez des balises personnalisées pour catégoriser les validations ou les mises en production en fonction des besoins ou flux de travail spécifiques de votre organisation. Par exemple, vous pouvez créer des balises telles que « documentation », « performances » ou « sécurité » pour classifier les validations en fonction de leurs domaines sur lequel elles se concentrent. Les balises personnalisées offrent une flexibilité supplémentaire pour organiser et structurer votre codebase en fonction des exigences de votre projet.

Implémentation

Pour affecter une balise à un référentiel Git dans GitHub, vous pouvez suivre les étapes suivantes :

  1. Identifiez le commit ou la version spécifique que vous souhaitez baliser dans votre référentiel. Vous pouvez trouver le code de hachage du commit ou la version commerciale dans l’historique des commits ou la section des versions de votre dépôt. Si vous balisez un commit, copiez le code de hachage du commit associé au commit que vous voulez baliser. Si vous balisez une version, copiez la version commerciale (par exemple, « v1.0.0 »).
  2. Dans un clone local du dépôt, utilisez la ligne de commande git tag pour créer une balise. La syntaxe de base pour la création d’une balise est balise git <tag_name><commit_hash>. Remplacez <tag_name> par le nom de votre balise et <commit_hash> par le hachage ou la version mise en production de la validation que vous avez copiée précédemment.
  3. Envoyez la balise à GitHub en exécutant la commande git push origin <tag_name>. Remplacez <tag_name> par le nom de la balise que vous avez créée.
  4. Après avoir envoyé la balise, vous pouvez vérifier qu’elle a été créée correctement en accédant à la page Mises en production\Balises de votre dépôt sur GitHub.

Vous pouvez créer des règles de protection des balises pour votre référentiel afin d’empêcher les contributeurs de créer ou de supprimer des balises. Toutefois, n’oubliez pas qu’à compter de mars 2024, les règles de protection des balises sont en version bêta et peuvent être modifiées.