Git
Chapters ▾ 2nd Edition

8.2 Personnalisation de Git - Attributs Git

Attributs Git

Certains de ces réglages peuvent aussi s’appliquer sur un chemin, de telle sorte que Git ne les applique que sur un sous-répertoire ou un sous-ensemble de fichiers. Ces réglages par chemin sont appelés attributs Git et sont définis soit dans un fichier .gitattributes dans un répertoire (normalement la racine du projet), soit dans un fichier .git/info/attributes si vous ne souhaitez pas que le fichier de description des attributs fasse partie du projet.

Les attributs permettent de spécifier des stratégies de fusion différentes pour certains fichiers ou répertoires dans votre projet, d’indiquer à Git la manière de calculer les différences pour certains fichiers non-texte, ou de faire filtrer à Git le contenu avant qu’il ne soit validé ou extrait. Dans ce chapitre, nous traiterons certains attributs applicables aux chemins et détaillerons quelques exemples de leur utilisation en pratique.

Fichiers binaires

Les attributs Git permettent des trucs cool comme d’indiquer à Git quels fichiers sont binaires (dans les cas où il ne pourrait pas le deviner par lui-même) et de lui donner les instructions spécifiques pour les traiter. Par exemple, certains fichiers peuvent être générés par machine et impossible à traiter par diff, tandis que pour certains autres fichiers binaires, les différences peuvent être calculées. Nous détaillerons comment indiquer à Git l’un et l’autre.

Identification des fichiers binaires

Certains fichiers ressemblent à des fichiers texte mais doivent en tout état de cause être traités comme des fichiers binaires. Par exemple, les projets Xcode sous macOS contiennent un fichier finissant en .pbxproj, qui est en fait un jeu de données JSON (format de données en texte JavaScript) enregistré par l’application EDI pour y sauver les réglages entre autres de compilation. Bien que ce soit techniquement un fichier texte en ASCII, il n’y a aucun intérêt à le gérer comme tel parce que c’est en fait une mini base de données. Il est impossible de fusionner les contenus si deux utilisateurs le modifient et les calculs de différence par défaut sont inutiles. Ce fichier n’est destiné qu’à être manipulé par un programme. En résumé, ce fichier doit être considéré comme un fichier binaire opaque.

Pour indiquer à Git de traiter tous les fichiers pbxproj comme binaires, ajoutez la ligne suivante à votre fichier .gitattributes :

*.pbxproj binary

À présent, Git n’essaiera pas de convertir ou de corriger les problèmes des CRLF, ni de calculer ou d’afficher les différences pour ces fichiers quand vous lancez git show ou git diff sur votre projet.

Comparaison de fichiers binaires

Dans Git, vous pouvez utiliser la fonctionnalité des attributs pour comparer efficacement les fichiers binaires. Pour ce faire, indiquez à Git comment convertir vos données binaires en format texte qui peut être comparé via un diff normal.

Comme c’est une fonctionnalité vraiment utile et peu connue, nous allons détailler certains exemples. Premièrement, nous utiliserons cette technique pour résoudre un des problèmes les plus ennuyeux de l’humanité : gérer en contrôle de version les documents Word. Tout le monde convient que Word est l’éditeur de texte le plus horrible qui existe, mais bizarrement, tout le monde persiste à l’utiliser. Si vous voulez gérer en version des documents Word, vous pouvez les coller dans un dépôt Git et les valider de temps à autre. Mais qu’est-ce que ça vous apporte ? Si vous lancez git diff normalement, vous verrez quelque chose comme :

$ git diff
diff --git a/chapter1.docx b/chapter1.docx
index 88839c4..4afcb7c 100644
Binary files a/chapter1.docx and b/chapter1.docx differ

Vous ne pouvez pas comparer directement les versions à moins de les extraire et de les parcourir manuellement. En fait, vous pouvez faire la même chose plutôt bien en utilisant les attributs Git. Ajoutez la ligne suivante dans votre fichier .gitattributes :

*.docx diff=word

Cette ligne indique à Git que tout fichier correspondant au patron (.docx) doit utiliser le filtre word pour visualiser le diff des modifications. Qu’est-ce que le filtre « word » ? Nous devons le définir. Vous allez indiquer à Git d’utiliser le programme docx2txt qui a été écrit spécifiquement pour extraire le texte d’un document MS Word, qu’il pourra comparer correctement.

Installez déjà docx2text. Vous pouvez le télécharger depuis https://docx2txt.sourceforge.net. Suivez les instruction dans le fichier INSTALL pour le placer à un endroit où votre shell peut le trouver. Ensuite, écrivons un script qui convertit la sortie dans le format que Git comprend. Créez un fichier dans votre chemin d’exécution appelé docx2txt et ajoutez ce contenu :

#!/bin/bash
docx2txt.pl $1 -

N’oubliez pas de faire un chmod a+x sur ce fichier. Finalement, vous pouvez configurer Git pour qu’il utilise ce script :

$ git config diff.word.textconv docx2txt

À présent, Git sait que s’il essaie de faire un diff entre deux instantanés et qu’un des fichiers finit en .docx, il devrait faire passer ces fichiers par le filtre word défini comme le programme docx2txt. Cette méthode fait effectivement des jolies versions texte de vos fichiers Word avant d’essayer de les comparer.

Voici un exemple. J’ai mis le chapitre 1 de ce livre dans Git, ajouté du texte à un paragraphe et sauvegardé le document. Puis, j’ai lancé git diff pour visualiser ce qui a changé :

$ git diff
diff --git a/chapter1.docx b/chapter1.docx
index 0b013ca..ba25db5 100644
--- a/chapter1.docx
+++ b/chapter1.docx
@@ -2,6 +2,7 @@
 This chapter will be about getting started with Git. We will begin at the beginning by explaining some background on version control tools, then move on to how to get Git running on your system and finally how to get it setup to start working with. At the end of this chapter you should understand why Git is around, why you should use it and you should be all setup to do so.
 1.1. About Version Control
 What is "version control", and why should you care? Version control is a system that records changes to a file or set of files over time so that you can recall specific versions later. For the examples in this book you will use software source code as the files being version controlled, though in reality you can do this with nearly any type of file on a computer.
+Testing: 1, 2, 3.
 If you are a graphic or web designer and want to keep every version of an image or layout (which you would most certainly want to), a Version Control System (VCS) is a very wise thing to use. It allows you to revert files back to a previous state, revert the entire project back to a previous state, compare changes over time, see who last modified something that might be causing a problem, who introduced an issue and when, and more. Using a VCS also generally means that if you screw things up or lose files, you can easily recover. In addition, you get all this for very little overhead.
 1.1.1. Local Version Control Systems
 Many people's version-control method of choice is to copy files into another directory (perhaps a time-stamped directory, if they're clever). This approach is very common because it is so simple, but it is also incredibly error prone. It is easy to forget which directory you're in and accidentally write to the wrong file or copy over files you don't mean to.

Git m’indique succinctement que j’ai ajouté la chaîne « Testing: 1, 2, 3. », ce qui est correct. Ce n’est pas parfait – les modifications de formatage n’apparaissent pas – mais c’est efficace.

Un autre problème intéressant concerne la comparaison de fichiers d’images. Une méthode consiste à faire passer les fichiers image à travers un filtre qui extrait les données EXIF, les méta-données enregistrées avec la plupart des formats d’image. Si vous téléchargez et installez le programme exiftool, vous pouvez l’utiliser pour convertir vos images en texte de méta-données de manière que le diff puisse au moins montrer une représentation textuelle des modifications pratiquées. Mettez la ligne suivante dans votre fichier .gitattributes :

*.png diff=exif

Configurez Git pour utiliser cet outil :

$ git config diff.exif.textconv exiftool

Si vous remplacez une image dans votre projet et lancez git diff, vous verrez ceci :

diff --git a/image.png b/image.png
index 88839c4..4afcb7c 100644
--- a/image.png
+++ b/image.png
@@ -1,12 +1,12 @@
 ExifTool Version Number         : 7.74
-File Size                       : 70 kB
-File Modification Date/Time     : 2009:04:21 07:02:45-07:00
+File Size                       : 94 kB
+File Modification Date/Time     : 2009:04:21 07:02:43-07:00
 File Type                       : PNG
 MIME Type                       : image/png
-Image Width                     : 1058
-Image Height                    : 889
+Image Width                     : 1056
+Image Height                    : 827
 Bit Depth                       : 8
 Color Type                      : RGB with Alpha

Vous pouvez réaliser rapidement que la taille du fichier et les dimensions des images ont changé.

Expansion des mots-clés

L’expansion de mots-clés dans le style de CVS ou de SVN est souvent une fonctionnalité demandée par les développeurs qui y sont habitués. Le problème principal de ce système avec Git est que vous ne pouvez pas modifier un fichier avec l’information concernant le commit après la validation parce que Git calcule justement la somme de contrôle sur son contenu. Cependant, vous pouvez injecter des informations textuelles dans un fichier au moment où il est extrait et les retirer avant qu’il ne soit ajouté à un commit. Les attributs Git vous fournissent deux manières de le faire.

Premièrement, vous pouvez injecter automatiquement la somme de contrôle SHA-1 d’un blob dans un champ $Id$ d’un fichier. Si vous positionnez cet attribut pour un fichier ou un ensemble de fichiers, la prochaine fois que vous extrairez cette branche, Git remplacera chaque champ avec le SHA-1 du blob. Il est à noter que ce n’est pas le SHA du commit mais celui du blob lui-même. Mettez la ligne suivante dans votre fichier .gitattributes :

*.txt ident

Ajoutez une référence $Id$ à un fichier de test :

$ echo '$Id$' > test.txt

À la prochaine extraction de ce fichier, Git injecte le SHA du blob :

$ rm test.txt
$ git checkout -- test.txt
$ cat test.txt
$Id: 42812b7653c7b88933f8a9d6cad0ca16714b9bb3 $

Néanmoins, ce résultat n’a que peu d’intérêt. Si vous avez utilisé la substitution avec CVS ou Subversion, il est possible d’inclure la date. Le code SHA n’est pas des plus utiles car il ressemble à une valeur aléatoire et ne vous permet pas de distinguer si tel SHA est plus récent ou plus ancien que tel autre.

Il apparaît que vous pouvez écrire vos propres filtres pour réaliser des substitutions dans les fichiers lors des validations/extractions. Ces filtres s’appellent « clean » et « smudge ». Dans le fichier .gitattributes, vous pouvez indiquer un filtre pour des chemins particuliers puis créer des scripts qui traiteront ces fichiers avant qu’ils soient extraits (« smudge », voir Le filtre « smudge » est lancé lors d’une extraction.) et juste avant qu’ils soient validés (« clean », voir Le filtre « clean » est lancé lorsque les fichiers sont indexés.). Ces filtres peuvent servir à faire toutes sortes de choses attrayantes.

Le filtre « smudge » est lancé lors d’une extraction.
Figure 143. Le filtre « smudge » est lancé lors d’une extraction.
Le filtre « clean » est lancé lorsque les fichiers sont indexés.
Figure 144. Le filtre « clean » est lancé lorsque les fichiers sont indexés.

Le message de validation d’origine pour cette fonctionnalité donne un exemple simple permettant de passer tout votre code C par le programme indent avant de valider. Vous pouvez le faire en réglant l’attribut filter dans votre fichier .gitattributes pour filtrer les fichiers *.c avec le filtre « indent » :

*.c filter=indent

Ensuite, indiquez à Git ce que le filtre « indent » fait sur smudge et clean :

$ git config --global filter.indent.clean indent
$ git config --global filter.indent.smudge cat

Dans ce cas, quand vous validez des fichiers qui correspondent à *.c, Git les fera passer par le programme indent avant de les valider et les fera passer par le programme cat avant de les extraire sur votre disque. Le programme cat ne fait rien : il se contente de régurgiter les données telles qu’il les a lues. Cette combinaison filtre effectivement tous les fichiers de code source C par indent avant leur validation.

Un autre exemple intéressant fournit l’expansion du mot-clé $Date$ dans le style RCS. Pour le réaliser correctement, vous avez besoin d’un petit script qui prend un nom de fichier, calcule la date de la dernière validation pour le projet et l’insère dans le fichier. Voici un petit script Ruby qui le fait :

#! /usr/bin/env ruby
data = STDIN.read
last_date = `git log --pretty=format:"%ad" -1`
puts data.gsub('$Date$', '$Date: ' + last_date.to_s + '$')

Tout ce que le script fait, c’est récupérer la date de la dernière validation à partir de la commande git log, la coller dans toutes les chaînes $Date$ qu’il trouve et réécrire le résultat. Ce devrait être simple dans n’importe quel langage avec lequel vous êtes à l’aise. Appelez ce fichier expand_date et placez-le dans votre chemin. À présent, il faut paramétrer un filtre dans Git (appelons le dater) et lui indiquer d’utiliser le filtre expand_date en tant que smudge sur les fichiers à extraire. Nous utiliserons une expression Perl pour nettoyer lors d’une validation :

$ git config filter.dater.smudge expand_date
$ git config filter.dater.clean 'perl -pe "s/\\\$Date[^\\\$]*\\\$/\\\$Date\\\$/"'

Cette commande Perl extrait tout ce qu’elle trouve dans une chaîne $Date$ et la réinitialise. Le filtre prêt, on peut le tester en écrivant le mot-clé $Date$ dans un fichier, puis en créant un attribut Git pour ce fichier qui fait référence au nouveau filtre et en créant un fichier avec votre mot-clé $Date$ :

date*.txt filter=dater
$ echo '# $Date$' > date_test.txt

Si vous validez ces modifications et extrayez le fichier à nouveau, vous remarquez le mot-clé correctement substitué :

$ git add date_test.txt .gitattributes
$ git commit -m "Testing date expansion in Git"
$ rm date_test.txt
$ git checkout date_test.txt
$ cat date_test.txt
# $Date: Tue Apr 21 07:26:52 2009 -0700$

Vous pouvez voir à quel point cette technique peut être puissante pour des applications personnalisées. Il faut rester néanmoins vigilant car le fichier .gitattributes est validé et inclus dans le projet tandis que le gestionnaire (ici, dater) ne l’est pas. Du coup, ça ne marchera pas partout. Lorsque vous créez ces filtres, ils devraient pouvoir avoir un mode dégradé qui n’empêche pas le projet de fonctionner.

Export d’un dépôt

Les données d’attribut Git permettent aussi de faire des choses intéressantes quand vous exportez une archive du projet.

export-ignore

Vous pouvez dire à Git de ne pas exporter certains fichiers ou répertoires lors de la génération d’archive. S’il y a un sous-répertoire ou un fichier que vous ne souhaitez pas inclure dans le fichier archive mais que vous souhaitez extraire dans votre projet, vous pouvez indiquer ce fichier via l’attribut export-ignore.

Par exemple, disons que vous avez des fichiers de test dans le sous-répertoire test/ et que ce n’est pas raisonnable de les inclure dans l’archive d’export de votre projet. Vous pouvez ajouter la ligne suivante dans votre fichier d’attribut Git :

test/ export-ignore

À présent, quand vous lancez git archive pour créer une archive tar de votre projet, ce répertoire ne sera plus inclus dans l’archive.

export-subst

Quand vous exportez des fichiers pour un déploiement, vous pouvez appliquer le formatage de git log et l’expansion de mot-clés à des portions choisies de fichiers marquées avec l’attribut export-subst.

Par exemple, si vous voulez inclure un fichier appelé LAST_COMMIT dans votre projet et y injecter automatiquement la date de dernière validation lorsque git archive est lancé, vous pouvez définir vos fichiers .gitattributes et LAST_COMMIT comme ceci :

LAST_COMMIT export-subs
$ echo 'Last commit date: $Format:%cd by %aN$' > LAST_COMMIT
$ git add LAST_COMMIT .gitattributes
$ git commit -am 'adding LAST_COMMIT file for archives'

Quand vous lancez git archive, le contenu de ce fichier inclus dans l’archive ressemblera à ceci :

$ git archive HEAD | tar xCf ../test-deploiement -
$ cat ../test-deploiement/LAST_COMMIT
Last commit date: Tue Apr 21 08:38:48 2009 -0700 by Scott Chacon

Les substitutions peuvent inclure par exemple le message de validation et n’importe quelle note git, et git log peut faire du simple retour à la ligne :

$ echo '$Format:Last commit: %h by %aN at %cd%n%+w(76,6,9)%B$' > LAST_COMMIT
$ git commit -am 'export-subst uses git log'\''s custom formatter

git archive uses git log'\''s `pretty=format:` processor
directly, and strips the surrounding `$Format:` and `$`
markup from the output.
'
$ git archive @ | tar xfO - LAST_COMMIT
Last commit: 312ccc8 by Jim Hill at Fri May 8 09:14:04 2015 -0700
       export-subst uses git log's custom formatter

         git archive uses git log's `pretty=format:` processor directly, and
         strips the surrounding `$Format:` and `$` markup from the output.

L’archive résultante est appropriée pour le travail de déploiement, mais comme n’importe quelle archive exportée, elle n’est pas appropriée pour continuer un travail de développement.

Stratégies de fusion

Vous pouvez aussi utiliser les attributs Git pour indiquer à Git d’utiliser des stratégies de fusion différenciées pour des fichiers spécifiques dans votre projet. Une option très utile est d’indiquer à Git de ne pas essayer de fusionner des fichiers spécifiques quand ils rencontrent des conflits mais plutôt d’utiliser prioritairement votre version du fichier.

C’est très utile si une branche de votre projet a divergé ou s’est spécialisée, mais que vous souhaitez pouvoir fusionner les modifications qu’elle porte et vous voulez ignorer certains fichiers. Supposons que vous avez un fichier de paramètres de base de données appelé database.xml différent sur deux branches et vous voulez les fusionner dans votre autre branche sans corrompre le fichier de base de données. Vous pouvez déclarer un attribut comme ceci :

database.xml merge=ours

Et définir une bête stratégie de fusion ours avec :

$ git config --global merge.ours.driver true

Si vous fusionnez dans une autre branche, plutôt que de rencontrer des conflits de fusion avec le fichier database.xml, vous verrez quelque chose comme :

$ git merge topic
Auto-merging database.xml
Merge made by recursive.

Dans ce cas, database.xml reste dans l’état d’origine, quoi qu’il arrive.

scroll-to-top