Suivre les versions logicielles est une tâche compliquée, et Git aide à la gérer. À l'aide du système de balisage de Git, vous pouvez créer des numéros de version versionnés qui pointent vers des commits spécifiques et les utiliser dans votre automatisation CI/CD pour publier des versions.
Étiquetage des releases dans Git
Les balises Git ressemblent beaucoup aux branches Git. Ce sont des étiquettes qui pointent vers des validations spécifiques et peuvent être utilisées pour extraire un référentiel à un moment précis. Cependant, contrairement aux branches, elles ne sont pas destinées à être mises à jour et modifiées et pointeront toujours vers une version spécifique.
Les balises sont couramment utilisées pour appliquer des numéros de version à des versions spécifiques, généralement à l'aide d'un contrôle de version sémantique. format (Majeur.Mineur.Patch). Ceci est très utile pour suivre les versions, en particulier lorsque des problèmes surviennent et que les déploiements doivent être rétablis à une balise précédente dont le fonctionnement est confirmé.
Les balises sont également utilisées pour signaler aux pipelines CI/CD qu'une version doit être publiée. Certains référentiels peuvent souhaiter publier un “dernier” release à chaque commit, en particulier lors de l'exécution de tests pour les branches de développement. Les balises sont souvent utilisées pour que les pipelines CI de publication ne s'exécutent et ne se déploient que sur demande spécifique.
Quand vous poussez vers une télécommande comme GitHub, vos balises apparaîtront sous l'onglet Releases, ce qui permet à quiconque de cloner ou de télécharger le référentiel à partir de cette balise.
Vous pouvez extraire des balises spécifiques avec la commande git checkout, dans de la même manière que l'extraction d'une branche fonctionne.
git checkout v1.0.0
Créer des balises
Créer une simple balise est très simple. Vous devrez vérifier le commit ou la branche que vous souhaitez baliser, puis exécuter git tag avec le nom de la balise.
git checkout master git tag v1.0.0
Cependant, c'est courant pratique d'utiliser des balises annotées, qui permettent de définir une description et de stocker des données supplémentaires sur qui les a créés et quand, un peu comme le font les commits.
git tag -a v1.0.0 -m “New Release Version – Summary”
Vous pouvez également baliser les commits antérieurs sans les vérifier :
git tag -a v1.2 commit_id
Les balises ne sont pas poussées vers des télécommandes comme GitHub avec la commande push par défaut de Git. Vous devrez l'exécuter avec –tags ou pousser le nom de la balise manuellement.
git push origin –tags
Suppression et modification des balises
Les balises peuvent également être supprimées, mais il est important de considérer que la suppression des balises des serveurs distants peut perturber les autres collaborateurs de votre référentiel. Cependant, étant donné que vous ne modifiez pas réellement l'historique Git, cela revient à supprimer une ancienne branche, ce qui ne touche pas les commits réels.
Vous pouvez supprimer des balises par leur nom avec le drapeau -d :
git tag -d v1.0.0
Et supprimez-les de la télécommande avec :
git push origin –delete v1.0.0
Pour modifier un tag, vous pouvez utiliser le drapeau -f pour forcer Git à écraser une balise existante :
git tag -f v1.0.0
Création de versions sur GitHub
GitHub prend également en charge les balises, mais les développe avec leurs propres “Releases& #8221; système. Les versions peuvent être faites à partir de balises, mais elles peuvent également être faites à partir de n'importe quel commit spécifique, ou avec le HEAD actuel de n'importe quelle branche.
L'objectif principal de la publication de versions est de fournir des fichiers binaires pré-construits à télécharger, ce qui est très utile sur GitHub mais que les balises elles-mêmes ne fournissent pas. Sinon, les utilisateurs auraient toujours besoin de cloner une balise spécifique et de construire à partir de la source.
L'autre objectif est de documenter les notes de publication, et GitHub Releases prend également en charge le démarquage. Cela offre aux utilisateurs un endroit agréable pour faire défiler les versions et voir les grands changements de version au fil du temps.
< p>Créer une version est assez facile. Dans la barre latérale de votre référentiel, cliquez sur “Versions,” et créez-en un nouveau :
Depuis cet écran, vous pouvez saisir des notes de version avec démarque et glisser-déposer le binaire fichiers pour la publication. GitHub vous fournira automatiquement un lien vers le code source de cette balise.
Vous pouvez créez également des versions automatiquement à partir de balises à l'aide de GitHub Actions. Cela vous évite de télécharger des fichiers binaires à chaque fois, ce qui est une belle automatisation pour votre dépôt.
LIRE LA SUITE
- › Google Bard AI propose de nouvelles fonctionnalités et des langues prises en charge
- › Les applications Microsoft 365 obtiennent une nouvelle police par défaut
- › Comment réparer “Le serveur de récupération n'a pas pu être contacté” Erreur Mac
- &rsaquo ; Windows 11 dit adieu aux anciennes applications ARM
- &rsaquo ; NotebookLM de Google change la donne pour la prise de notes
- › 1Password accélère votre processus de connexion