les balises
Les balises dans Git constituent un bon moyen d’indiquer une version de votre code, ou bien si vous avez besoin de pouvoir faire référence à un commit de votre historique de gestion de version. Cet article va parcourir les bonnes (et les moins bonnes) pratiques relatives à l’utilisation de git tag.
La meilleure manière de décrire une balise serait “un post-it relatif à un commit”. Il a un nom, par exemple v1.0.0 ou production, et un message si vous en précisez un. Git pour l’informatique scientifique représente un tag ainsi:
Soit, mais comment créer un tag ? Simplement git tag v1.0.0 non ? C’est FAUX. Vous devez généralement éviter de faire comme ça. En réalité, on dit que cette commande constitue une mauvaise pratique par défaut. Sans arguments, git tag crée un tag “poids plume” qui est simplement une branche qui ne bougera pas. Ces tags poids plume sont cependant utiles, pour marquer une version connue comme étant à rejetter (ou bien garder), ou un ensemble de commits que vous pourriez utliser à l’avenir. Néanmoins, vous ne devez pas trop utiliser ces balises.
Ainsi, vous devez au moins passez au moins l’option -a pour créer une balise non-signée, ou signer la balise avec votre clé GPG key via l’option -s ou -u <key-id>. Apès, vous pouvez utiliser git describe pour obtenir le nombre de commit créés depuis la dernière balise ou une balise donnée. Git-fu a un didacticiel complet concernant l’utilisation de cette commande ( et cela mérite une description complète dans une de nos prochaines astuces !).
Créons une nouvelle balise et observons comment nous pouvons y faire référence même après avoir ajouté des commits, et envoyé ce qui a été taggé sur le dépôts distant. C’est plus simple que vous ne le pensez.
$ git tag -a v1.0.0 -m "Creating the first official version."
$ git show v1.0.0
tag v1.0.0
Tagger: Nick Quaranto <nick@quaran.to>
Date: Tue Feb 3 20:37:45 2009 -0500
Creating the first official version.
commit a8d1b55c5d4bdec843d9942cabf1b678bc1d4eed
Merge: 00b9675... 1b487b8...
Author: Nick Quaranto <nick@quaran.to>
Date: Sun Nov 30 00:41:08 2008 -0500
Merge branch 'master' of git@github.com:qrush/config
$ git describe --tags
v1.0.0
$ touch test
$ git add test
$ git commit -am "Adding test files"
Created commit a7aafb8: Adding test files
0 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 test
$ git describe --tags
v1.0.0-1-ga7aafb8
$ git push --tags
Counting objects: 40, done.
Compressing objects: 100% (37/37), done.
Writing objects: 100% (40/40), 29.32 KiB, done.
Total 40 (delta 15), reused 9 (delta 2)
To git@github.com:qrush/config.git
* [new tag] v1.0.0 -> v1.0.0
La deuxième commande describe nous montre que nous somme à un commit en plus de l’état dans lequel le tag a été attribué. C’est un moyen simple de voir combien de travail a été effectué depuis le dernier commit. De plus, l’option --tags a été utilisé pour faire l’envoi, mais il est possible d’envoyer le tag en utilisant git push origin v1.0.0. Sur GitHub (ou sur votre dépôt remote) vous devriez voir apparaitre la balise suivante :
Autre chose, si vous avez envoyé des balises que vous voulez déplacer ou renommer, Git rend les choses ridiculement pénible à faire. Consulter le manuel pour une explication de la raison de cette difficulté et purquoi cela doit être fait avec soin.
Si vous avez un moyen bien à vous d’intégrer les balises dans votre manière de travailler avec Git, parler en dans les commentaires ou bien proposer une astuce qui profitera à tout le monde !
