Objectif: Suivre de manière efficace l’évolution des fichiers d’un projet logiciel contrôlé par Git. Utiliser les tags git pour marquer les versions de cette évolution. Pré-requis: Git est installé et confiiguré sur un système GNU/Linx (article 1 de la serie « Tuto Git ». Les commandes de base sont connues et les manipulations de l’article qui traite des fusions exécutées.

1. Visualiser les traces de l’évolution d’un fichier

On considère la situation atteinte à la fin du précédent article de la serie « Tuto Git ». DEV1 (cd /pcdev1) souhaite visualiser l’avolution du fichier README. Il exécute:

git log README

Le résultat obtenu est le suivant, marqué en couleur jaune l’indication de la fusion effectuée:

Trace de l’évolution du fichier README

Cette visualisation peut être améliorée en utilisant le paramètre graph:

git log --graph README

Le résultat obtenu est le suivant, marqué en couleur jaune l’indication de la fusion effectuée. Remarquer l’indication du conflit par la segmentation du « parcours » du fichier dans le temps:

Trace de l’évolution du fichier README avec représentation graphique

2. Créer un tag pour un projet

A tout moment au cours de l’évolution du projet on peut poser un tag sur l’ensemble du dépôt de fichiers source. Ceci permet de revenir ultérieurement vers cette image du projet. Dans la pratique un tag est posé à chaque fois que le projet atteint un certain niveau de maturité, notamment à l’occasion de la diffusion d’une version. DEV2 (cd /pcdev2) ajoute d’abord la ligne suivante à la fin du fichier README:

Evolution de la version 1.0

Ensuite il pose un tag pour marquer la version 1.0

git tag -a v1.0 -m "Version 1.0"
git commit -am "Evolution vers une version stable"
git push
git tag

Remarquer la réponse à la dernière commande qui permet d’afficher la liste des tags disponibles. DEV1 (cd /pcdev1) récupère cette évolution et regarde s’il y a des tags:

git pull
git tag

Curieusement aucun tag n’apparaît. L’explication à ceci est que le tag posé par DEV2 est resté local au dépôt de DEV2, un push simple ne permet pas d’envoyer les tags sur le serveur. Pour remedier à cela DEV2 (cd /pcdev2), exécute de son côté:

git push --tags

Maintenant DEV1 récupèrera le tag posé après un git pull.

3. Revenir à une version (tag) précédente du projet

Après avoir récupéré les dernières modifications avec le tag, DEV2 exécute, pour récupérer la version 1.0:

git checkout v1.0
cat README

La commande checkout permet ivc de se positionner sur un tag existant. Encore une fois curieusement, le contenu de README affiché avec la commande cat ne montre pas la dernière mise à jour (ajout de la ligne « Evolution de la version 1.0 »). Ce “mystère” peut être illucidé grâce à la commande:

git log --decorate README

La réponse à cette commande est: On est bien positionné sur le tag v1.0 (premier commit dans la liste) mais ce commit n’est pas le dernier en date. La cause est que le tag a été posé avant le dernier commit (paragraphe 2). Le tag est créée est positionné sur le dernier commit existant au moment de la création. Pour s’assurer de cette explication, DEV2 exécute successivement les commandes:

git checkout master
git log --decorate --graph README

La commande git checkout master permet de revenir à tout moment au dernier commit en date. La réponse à ces commandes est: La commande cat README permet de s’assurer également que le contenu de ce fichier est bien celui de la dernière mise à jour.]]>