Woodgate.fr

Julien Ramel

Ingénieur Recherche & Développement, passionné par le Web et ses technologies. Responsable Technique de Wax Interactive Suisse. Lyonnais expatrié à Lausanne.


Git like a boss : tagging et extractions différentielles



Lorsqu'on veut être agile il est nécessaire de savoir automatiser au maximum certaines tâches récurrentes, comme par exemple la livraison de code à un client. On peut parfois être amené à faire 3, 5, 10... 50 livraisons d'un même projet, que ce soit pour l'intégration de patchs ou de nouvelles fonctionnalités.

Il y a donc une chose primordiale à connaître : l'état de l'art du code d'un projet chez le client, c'est à dire la dernière version livrée. Il n'est pas imaginable d'aller chercher en permanence dans ses emails la dernière livraison qui a été réalisée, on doit pouvoir connaître en un clin d'oeil les dernières étapes techniques d'un projet et c'est pourquoi on a inventé le versioning (ou le versionnage en français).

De ce fait, nous savons qu'un projet en version 1.0 sera antérieur à la version 1.1, qui en sera de même à la version 2.0.1, et ainsi de suite. On appelle ça un numéro de version, ou versioning sémantique.

Le but de cet article est de vous initier au versioning avec Git ainsi qu'à l'export différentiel de données entre deux versions d'un projet managé avec Git.

Git

Tagging avec Git

Première information : Git intègre nativement une fonctionnalité de tagging (deux, en fait) qui permet d'associer un numéro de version à un commit. Et c'est là tout l'intérêt : nous allons par exemple tagger 1.0 le dernier commit qui a été réalisé au moment d'une livraison d'un projet, puis 1.1 à la livraison suivante, et ainsi de suite.

Notez qu'on parle ici de lightweight tags, ou tags légers.

Via la ligne de commande

Le scénario est le suivant : on fait un commit, et on lui associe après-coup un numéro de version. Pour tagger un commit en connaissant son ID :

git tag 1.0 95665c89dc3a574dd322ccedab171403855f062b

Pour récupérer l'ID du dernier commit, on peut faire :

git log --format="%H" -n 1

Il est aussi possible d'associer un tag à la copie de travail parente sans devoir spécifier l'ID du dernier commit :

git tag 1.0

Il faudra alors pousser le tag.

Via notre client Git préféré

Inutile de lancer le débat sur l'utilité d'un client Git avec interface graphique, c'est une question de goût. Pour ma part j'utilise régulièrement SourceTree. Celui-ci permet de tagger un commit en 2 clics.

Tagging

Le numéro de version est alors affiché dans la liste des commits, pour une représentation visuelle très pratique.

SourceTree

Tagging

Extraction différentiel de données

Seconde information : Git intègre des outils qui permettent (moyennant quelques options) de faire des extractions des données (des fichiers) qui ont été modifiées entre deux commits ou deux numéros de version.

Voici la commande que j'utilise quotidiennement :

cd /path/to/project/ && git archive --output=../Project-1.1.zip --verbose HEAD $(git diff --cached --name-only 1.0)

Explications

  • On se rend dans le dossier du projet
  • On génère un fichier ZIP Project-1.1.zip dans son dossier parent
  • Le fichier va contenir le différentiel des fichiers entre l'état actuel du projet (dernier commit) et le tag 1.0
  • L'option --verbose permet pour un contrôle de lister les fichiers exportés par la commande

Il est alors possible de fournir le fichier Project-1.1.zip au client, et celui-ci ne comprendra que les fichiers qui ont été modifiés depuis la version 1.0 du projet, avec toute l'arborescence nécessaire (tous les sous-dossiers).

Dans la commande, 1.0 peut au besoin être remplacé par l'identifiant d'un commit (ID). Notez par ailleurs que ce paramètre correspond à l'identification du commit précédent le début de l'extraction. Autrement dit le commit taggé 1.0 ici ne sera pas inclu dans l'extraction, mais le commit suivant le sera. C'est le scénario voulu car l'extraction de la version 1.1 du projet ne doit contenir que les fichiers modifiés à la suite du dernier commit de la version 1.0.

Export

Conclusion

Nous avons maintenant une solution clé en main afin de pouvoir générer facilement des livraisons de nos projets. Mieux, nous sommes en mesure de suivre dans Git l'historique de notre projet et de ses livraisons.

J'en profite pour ajouter qu'il me paraît nécessaire de documenter l'historique de vos projet avec un ChangeLog qui devrait idéalement suivre le tagging sur Git et contenir les dates, les auteurs des modifications, etc. En général je fais en sorte que le ChangeLog soit toujours livré dans un extraction de version d'un projet.

De même, j'affiche le numéro de version dans le code source de mes projets : ça me permet de savoir en un coup d'oeil si un projet sur un serveur distant (auquel je n'ai pas forcément accès) a été mis à jour. Cela peut se traduire par exemple par l'inclusion d'un fichier version.txt présent à la raçine du projet et contenant le numéro de version de celui-ci.

Version

N'hésitez pas à me suivre sur Twitter (@Woodgate) si vous souhaitez en discuter.


comments powered by Disqus