Lors de mes développements avec Git, j’ai été confronté a un problème : cacher des fichiers spécifiques à mon environnement de développement personnel dans mes projets.
[EDIT] : Avant de commencer, comme le souligne dzamlo dans les commentaires, il est possible d’utiliser également le fichier « .git/info/exclude » pour ne pas versionner des fichiers spécifiques à votre environnement. Vous trouverez plus d’informations ici.
Le problème : un ou des fichier(s) spécifique(s) à votre environnement
Voici un exemple concret, sur un de mes projet professionnel:
Dans l’environnement de développement, il existe un fichier à nommer en fonction du nom de l’utilisateur de la session Mac/Linux. Ce fichier est obligatoire avec les technologies utilisées (legacy code…).
Concrètement, il y a un fichier build.USERNAME.properties dans le projet. Avec USERNAME, le nom de l’utilisateur de la session. L’exemple est représenté sur le schéma suivant :
Ce fichier « build.USERNAME.properties » ne doit donc pas être versionné, car spécifique à l’environnement de développement. Il existe des solutions qui peuvent paraitre évidente comme ajouter une entrée par développeur dans le .gitignore de la racine du projet, mais cette solution :
- n’est pas une solution perenne
- rendra le « .gitignore » moins lisible avec pas mal de lignes parasites
De même, demander à chaque développeur d’ajouter le fichier à ignorer dans le « .gitignore » en local est une mauvaise solution (encore pire que la première). Le « .gitignore » apparaîtra en continue comme modifié dans le versionning et il sera régulièrement commité par erreur.
Une solution : Ignorer un Git Ignore et y ajouter le fichier à cacher
Il existe une solution simple, elle consiste à ajouter dans le « .gitignore » à la racine du projet (par exemple), un « .gitignore » à ignorer dans le même répertoire ou dans un répertoire au-dessus du fichier à cacher. Le « .gitignore » créé ne sera alors pas soumis au versionning, mais il sera pris en compte par Git!
Je pense que vous le sentez venir, il faut ajouter le fichier « build.USERNAME.properties » dans le « .gitignore » créé.
Cette méthode permet de ne pas versionner l’ensemble des fichiers spécifiques à votre environnement qui n’ont rien à faire sur votre serveur Git. Tout en étant, une solution pérenne car la création et le paramétrage du « .gitignore » est à faire uniquement lors du checkout initial du projet.
Partager l'article :
Dans ce cas spécifique, pourquoi ne pas ajouter « build.*.properties » dans le .gitignore?
De manière générale, l’utilisation de .git/info/exclude n’est elle pas plus adapté pour ignorer localement des fichiers?
Oui et non, dans ce cas précis ajouter « build.*.properties » peut être une solution.
Cependant, il y a souvent un fichier de référence, nommé par exemple « build.SAMPLE.properties », ajouter « build.*.properties » enlèverai ce fichier du versionning.
Je viens de regarder « .git/info/exclude » (que je ne connaissais pas) c’est une alternative probablement plus rapide. Je modifie l’article pour compléter .
Merci pour ce retour!
Dans ce cas, il est possible de « designorer » le fichier de reference en ajoutant « !build.SAMPLE.properties » dans le .gitignore
J’oublie tout le temps la « designoration » ( 😀 ), c’est une solution intéressante du coup!
Si tu veux pas repeter l’operation pour chaque dépot tu peux faire une gitignore global:
Exemple pour ignore les fichiers de backup de vim dans tout les repos git:
git config –global core.excludesfile ~/.gitignore
cat > ~/.gitignore <<EOF
*~
EOF
C’est ce que j’ai fais dans le cadre de mon projet, mais je ne le conseille pas. Mon environnement est (malheureusement) très statique j’ai donc très peu de modification à faire pour le maintenir à jour.
Ta solution est proche de la proposition de dzamlo d’utiliser le fichier .git/info/exclude qui est fait pour cela.
Comme dzamlo je préfère le wildcard + « designorer ». Ça me paraît plus propre et c’est fait une fois pour toute.
Dans ton exemple Il faudrait que chaque dev recréer un .gitignore avec le nom de son fichier à chaque récupération du projet. C’est assez lourd et facile à oublier.
Je note quand même le tips qui pourrait être utile un jour ou sur un projet monté comme dans ton exemple 😉
Merci pour ton retour,
Oui dans mon cas précis, ce n’est pas la solution optimale, plus lourde que celle proposé par dzamlo. Mais je me suis servi de cette technique (équivalent au .git/info/exclude, comme la signalé dzamlo encore une fois) pour cacher d’autres fichiers spécifiques. Par exemple dans mon cas, des fichiers présents à des fins de tests manuels (oui ça existe encore).
NB : J’ai beaucoup aimé ton article sur la gestion de plusieurs versions avec GitFlow!