Commandes git utiles - Gestion des étiquettes (tags management)
Gestion des étiquettes (tags).
Pendant la phase de développement, nous sommes souvent amenés à livrer des versions de logiciels, modules et sites web, dans différents environnements tels que Développement, Intégration Continue (IC), Assurance Qualité (QA), Tests d'acceptance utilisateur (UAT), Pré-Production ou Production.
On peut vouloir livrer une version en "release-candidate" en UAT, ou une version finale en Production. Ceci implique de gérer d'une part les versions, mais aussi les itérations de développement sur ces versions.
Avec git, chaque commit à un numéro de commit unique. Vous pourriez donc avoir un référentiel avec le numéro de commit pour chaque module, dans chaque environnement.
Le désavantage de ne stocker que le numéro de commit est que ça ne vous donne pas autant d'information et de simplicité que de gérer des numéros de version.
Git vous permet de gérer des numéros de version via deux types d'étiquetage (deux types de tags) :
-
Etiquette légère (ou "Lightweight tag") : C'est une étiquette dite simple, ou temporaire. C'est simplement un pointeur sur un commit spécifique.
-
Etiquette annotée (ou "Annotated tag") : C'est une etiquette plus complète qui est stockée en tant qu'objet dans la base de données de git. L'objet en question inclue des informations comme le nom du créateur, la date, un message, un checksum pour le tag (qui garanti l'intégrité et qui peut être signé électroniquement).
Bien que le système d'étiquetage avec des étiquettes légères peut sembler suffisant dans certains cas, les étiquettes annotées sont souvent privilégiées parce qu'elle amènent beaucoup plus d'information. Vu que les mécanismes pour déposer ces deux types d'étiquettes sont similaires et très proche, nous recommandons largement d'utiliser des étiquettes annotées pour gérer vos versions.
Aperçu des commandes pour gérer les étiquettes (les tags)
Lister les étiquettes sur un projet
git tag
Chercher des étiquettes spécifiques avec un pattern
$ git tag -l "v1.3.*"
v1.3.0
v1.3.0-rc1
v1.3.0-rc2
v1.3.1
v1.3.1-rc1
v1.3.2-rc1
Pour récupérer la liste des derniers tags, utiliser fetch
$ git fetch
Pour voir sur quelle étiquette nous sommes "synchronisés"
$ git describe --tag
Pour créer des étiquettes
Pour créer une étiquette légère
$ git tag v1.3.2lw
$ git tag
v1.3.1
v1.3.2
v1.3.2lw
$ git show v1.3.2lw
commit 0dfc5dac3d8bf17f833e21ae6ce7bc3ea19a03fa
Author: Gerald Colin <xyz2@xyz.com>
Date: Sat Aug 22 16:17:12 2015 -0700
some comments.
Pour créer une étiquette annotée
$ git tag -a v1.3.2a -m "version 1.3.4 annotated"
$ git show v1.3.2a
tag v1.3.2a
Tagger: Denis Garcia <xyz1@xyz.com>
Date: Fri Apr 4 22:33:50 2016 +0200
version v1.3.2 annotated
commit 0dfc5dac3d8bf17f833e21ae6ce7bc3ea19a03fa
Author: Gerald Colin <xyz2@xyz.com>
Date: Sat Aug 22 16:17:12 2015 -0700
some comments.
Pour pousser une étiquette spécifique sur le dépôt git distant
$ git push origin v1.3.2
Pour pousser toutes les étiquettes sur le dépôt git distant
$ git push origin --tags
Pour mettre à jour le code sur l'étiquette v1.3.2 en restant sur la branche courante
$ git checkout v1.3.2
Pour mettre à jour le code sur l'étiquette v1.3.2 sur une nouvelle branche que l'on veut créer au passage
git checkout -b hotfix-1.3.2-hf1 v1.3.2
Et si on veut revenir sur un tag,
pour le supprimer en remote:
git push --delete origin v1.3.2
pour le supprimer en local:
git tag --delete v1.3.2
Conclusion
En développant un site web, un logiciel ou n'importe quelle module, il est recommandé d'utiliser un étiquetage avant de livrer ce code. Git est très puissant pour ça.
Il y a beaucoup à lire sur le sujet du versioning de code source sur internet et nous aurons l'occasion de couvrir largement ce sujet intéressant et important dans quelques articles à venir.