Présent dans tout repository git mais bien souvent mis de côté, le fichier .gitignore est pourtant essentiel ! Que cela soit pour éviter de surcharger votre répertoire distant ou pour une question de sécurité, le .gitignore est d’une importance capitale.
Et ce petit fichier est bien plus puissant que ce que l’on pense !
Vous vous intéressez à cet outil de Git, son fonctionnement, ses règles ? Vous voulez apprendre à l’utiliser et à exploiter toutes ses capacités ? Suivez le guide !
Git et sa gestion des fichiers
Pour bien comprendre comment fonctionne le .gitignore et à quel point il est utile, il faut s’intéresser un peu à la façon dont Git gère les fichiers.
Du point de vue de Git, un fichier ne peut être que dans un des 3 états suivants :
- non tracké, qui n’a pas été commité ;
- tracké, qui a été commité ;
- ignoré, que git ignore complètement.
C’est donc à cette troisième catégorie que nous allons nous intéresser.
À travers le fichier .gitignore, on vient dire explicitement au logiciel de gestion de source, via une liste textuelle, que certains fichiers ou dossiers doivent être ignorés lors d’un commit. De cette manière, on se retrouvera avec des éléments en local, qui ne seront jamais poussés sur le serveur distant.
Gitignore et les fichiers ignorés
Pourquoi mettre en place un .gitignore ?
On le sait maintenant, le fichier .gitignore sert à lister les fichiers et répertoires qui seront ignorés lors du commit. Mais, concrètement, quels types de fichiers doivent être ignorés, et pourquoi ?
On ajoutera d’abord au .gitignore tous les fichiers générés, qui n’ont pas besoin d’être stockés sur le serveur, notamment pour un gain de place. Ce seront par exemple les dépendances installées (type node_modules), les builds (qui seront générés de nouveau de toute façon) ou les fichiers de logs.
Mais, en dehors du gain d’espace, mettre en place le .gitignore est aussi une question de sécurité.
Un projet doit bien souvent contenir des données sensibles, stockées dans des fichiers de configuration. Il peut s’agir de clés d’API, ou bien d’identifiants pour se connecter à une base de données. Il faut éviter de commiter ce genre d’informations, car il est possible que quelqu’un arrive à se connecter frauduleusement à un compte autorisé, ou trouve le moyen d’avoir accès au repository. Et, évidemment, des identifiants de base de données ne doivent pas tomber entre toutes les mains.
Ce sont des informations qu’on gardera en local, et qu’on interdira à Git de commiter.
Le fonctionnement du .gitignore
Techniquement, le fichier .gitignore n’est qu’un fichier texte contenant une liste de noms de fichiers ou dossiers à ignorer. En voici un exemple :
.DS_Store
Thumbs.db
UserInterfaceState.xcuserstate
/node_modules
Ce fichier se trouve à la racine d’un repository. Lors de certaines commandes Git (le ‘git add’, notamment), ce fichier sera lu et les éléments listés seront ignorés.
Il est également possible d’avoir des règles spécifiques pour chaque sous-répertoire. Dans ce cas-là, il faudra créer un .gitignore dans chacun des répertoires auxquels on veut appliquer ces règles particulières.
Le gitignore est lui commité, et donc partagé par toute l’équipe de développement. Les fichiers et dossiers qui y sont définis comme ‘non commitables’ seront donc les mêmes pour tous les développeurs freelance. Il est néanmoins possible d’avoir des règles spécifiques, propres à une machine. Elles sont à écrire dans le fichier .git/info/exclude.
Les règles du fichier .gitignore
Maintenant que nous savons tout du fonctionnement du gitignore, voyons quelles règles s’appliquent à l’écriture de ce fichier. Car non, le .gitignore ne contient pas qu’une liste de noms ! Il existe des règles qui permettent d’affiner tout cela. Voyons les principales.
Pour l’exemple simple, voici deux lignes systématiquement ajoutées au .gitignore :
.DS_Store
Thumbs.db
Ces fichiers sont des éléments cachés par les systèmes d’exploitation (respectivement par macOS et Windows). Ils ne sont d’aucune utilité dans un projet. Aussi, il ne sert à rien de les commiter : ils seraient plus encombrant qu’autre chose.
Voyons maintenant d’autres règles plus complexes, avec leurs explications :
# est un commentaire, sera ignoré
*.tmp # tous les fichiers terminant par '.tmp' seront ignorés
!important.tmp # sauf le fichier important.tmp, qui lui sera commité
/node_modules # tout ce qui se trouve dans le dossier 'node_modules' sera ignoré
debug?.log # le '?' remplace *un* caractère. Ainsi seront ignorés debug0.log, comme debug9.log
www/**/*.apk # tous les fichiers .apk qui se trouvent dans n'importe quel dossier à partir de www/ seront ignorés
Ce ne sont que des exemples ! Pour encore plus de règles, reportez-vous à cette documentation.
Voir aussi : Git, toutes les commandes indispensables aux développeurs.
Le contenus type du fichier .gitignore
Quelques exemples de .gitignore
Pour avoir une idée un peu plus concrète du contenu d’un fichier .gitignore, voyons quelques exemples pris de la documentation officielle de Git.
# exclude everything except directory foo/bar
/*
!/foo
/foo/*
!/foo/bar
# ignore objects and archives, anywhere in the tree.
*.[oa]# ignore generated html files,
*.html
# except foo.html which is maintained by hand
!foo.html
Les générateurs et templates de .gitignore
En théorie, les outils de création de projet et frameworks définissent eux-mêmes les contenus des .gitignore.
Néanmoins, si vous avez besoin de partir sur une base non existante, il existe des templates et des générateurs de .gitignore.
On retrouve dans le compte officiel de GitHub (sur GitHub) une liste de tous les templates de .gitignore qu’ils utilisent. C’est notamment utile si vous devez changer ou adapter une technologie sur un projet existant.
Il existe aussi des générateurs de fichiers .gitignore. Comme ce site, qui, à partir d’une techno donnée, crée un fichier .gitignore contenant toutes les bases nécessaires à un projet.
Aller plus loin avec le .gitignore
Nous avons vu à présent tout ce qu’il faut savoir sur le fichier .gitignore pour pouvoir en créer un propre, avec des règles personnalisées et correspondantes à un projet spécifique.
Pour aller un peu plus loin, voyons deux cas d’utilisation spécifique du .gitignore : comment mettre un fichier déjà commité dans le .gitignore, et comment forcer le commit d’un fichier pourtant présent dans le .gitignore.
Ignorer un fichier déjà commité
Ce cas peut survenir si, par exemple, vous avez commité un fichier ou répertoire qui ne doit pas l’être – ou qui ne doit plus l’être. Prenons l’exemple d’un fichier de configuration : env.development.local.
Pour qu’il soit ignoré, il faudra ajouter la ligne correspondante (‘env.development.local’) dans le fichier .gitignore. Puis exécuter les commandes git suivantes :
git rm --cached env.development.local
git commit -m "start ignoring env.development.local"L’option cached permet de garder une copie du fichier en local (il faudra donc la retirer si vous voulez également supprimer le fichier de votre machine).
Forcer le commit d’un fichier ignoré
Maintenant, le cas d’utilisation contraire ! Vous avez un fichier listé dans votre .gitignore, mais voulez quand même le commiter. Pour cela, il suffit d’utiliser l’option force de git :
git add -f env.example.local
git commit -m "Force adding env.example.local"Toutefois, ce n’est pas une bonne pratique. Mieux vaut trouver de meilleures solutions, comme l’exception dans le fichier .gitignore (avec le point d’exclamation précédant le nom du fichier). Cela sera plus propre et maintenable, notamment si vous travaillez à plusieurs sur le même repository.
Conclusion
Nous l’avons vu, le fichier .gitignore, inclus dans les projets git, est bien plus qu’un simple fichier servant à ignorer quelques éléments cachés ou les modules.
Via des règles spécifiques, il est possible de pousser la personnalisation de cet outil Git, et d’ainsi gérer mieux son projet, le sécuriser, l’optimiser, et le rendre plus maintenable si on travaille en équipe.
Connaissiez-vous toutes ces utilisations du fichier .gitignore ? En avez-vous d’autres ? Dites-nous tout en commentaire !
