Git considère chaque fichier de votre copie de travail comme appartenant à l'un des trois types suivants :

  1. tracké : un fichier qui a été stagé ou commité au préalable ;
  2. non tracké : un fichier qui n'a pas été stagé ou commité ; ou
  3. ignoré : un fichier que Git a explicitement reçu pour instruction d'ignorer.

Les fichiers ignorés sont généralement des artefacts de build et des fichiers générés par la machine qui sont dérivés de votre dépôt source ou qui ne devraient pas être commités. Quelques exemples fréquents :

  • caches de dépendance, comme le contenu de /node_modules ou /packages
  • le code compilé, comme les fichiers .o, .pyc et .class ;
  • les répertoires de sortie de build, comme /bin, /out ou /target ;
  • les fichiers générés lors de l'exécution, comme .log, .lock ou .tmp ;
  • les fichiers système cachés, comme .DS_Store ou Thumbs.db ;
  • fichiers de configuration IDE personnels, comme .idea/workspace.xml

Les fichiers ignorés sont trackés dans un fichier spécial appelé .gitignore qui est enregistré à la racine de votre répertoire. Il n'existe pas de commande Git ignore explicite : à la place, le fichier .gitignore doit être édité et commité manuellement lorsque vous souhaitez ignorer de nouveaux fichiers. Les fichiers .gitignore contiennent des modèles mis en correspondance avec les noms des fichiers de votre dépôt pour déterminer s'ils doivent ou non être ignorés.

Modèles Git ignore

.gitignore utilise des modèles de développement pour s'adapter aux noms de fichiers. Vous pouvez créer vos modèles avec différents symboles :

Modèle Exemples de correspondances Explication*
**/logs logs/debug.log
logs/monday/foo.bar
build/logs/debug.log
Vous pouvez préfixer un modèle avec un double astérisque pour qu'il corresponde aux répertoires partout dans le dépôt.
**/logs/debug.log logs/debug.log
build/logs/debug.log
mais pas
logs/build/debug.log
Vous pouvez également utiliser un double astérisque pour faire correspondre les fichiers en fonction de leur nom et du nom de leur répertoire parent.
*.log debug.log
foo.log
.log
logs/debug.log
Un astérisque est un caractère générique qui correspond à zéro caractère ou plus.
*.log
!important.log
debug.log
trace.log
mais pas
important.log
logs/important.log
Préfixer un point d'exclamation à un modèle l'invalide. Si un fichier correspond à un modèle, mais également à un modèle invalidant défini ultérieurement dans le fichier, il ne sera pas ignoré.
*.log
!important/*.log
trace.*
debug.log
important/trace.log
mais pas
important/debug.log
Les modèles définis après un modèle invalidant ignoreront à nouveau tout fichier invalidé au préalable.
/debug.log debug.log
mais pas
logs/debug.log
Préfixer une barre oblique associe uniquement des fichiers dans la racine du dépôt.
debug.log debug.log
logs/debug.log
Par défaut, les modèles correspondent aux fichiers de tout répertoire
debug?.log debug0.log
debugg.log
mais pas
debug10.log
Un point d'interrogation correspond exactement à un caractère.
debug[0-9].log debug0.log
debug1.log
mais pas
debug10.log
Vous pouvez également utiliser des crochets pour faire correspondre un caractère unique d'une plage spécifique.
debug[01].log debug0.log
debug1.log
mais pas
debug2.log
debug01.log
Les crochets correspondent à un caractère unique de l'ensemble spécifié.
debug[!01].log debug2.log
mais pas
debug0.log
debug1.log
debug01.log
Un point d'exclamation peut être utilisé pour associer n'importe quel caractère, sauf ceux provenant de l'ensemble spécifié.
debug[a-z].log debuga.log
debugb.log
mais pas
debug1.log
Les plages doivent être numériques ou alphabétiques.
logs logs
logs/debug.log
logs/latest/foo.bar
build/logs
build/logs/debug.log
Si vous n'ajoutez pas de barre oblique, le modèle correspond aux fichiers et au contenu des répertoires portant ce nom. Dans les exemples de correspondance sur la gauche, les répertoires et les fichiers appelés logs sont ignorés
logs/ logs/debug.log
logs/latest/foo.bar
build/logs/foo.bar
build/logs/latest/debug.log
L'ajout d'une barre oblique indique que le modèle est un répertoire. Le contenu entier de tout répertoire du dépôt correspondant à ce nom (y compris tous ses fichiers et sous-répertoires) sera ignoré.
logs/
!logs/important.log
logs/debug.log
logs/important.log
Attendez un peu. Ne faudrait-il pas annuler logs/important.log dans l'exemple de gauche ?

Non ! En raison d'une singularité due aux performances dans Git, vous ne pouvez pas annuler un fichier qui est ignoré suite à une correspondance de modèle avec un répertoire
logs/**/debug.log logs/debug.log
logs/monday/debug.log
logs/monday/pm/debug.log
Une double astérisque correspond à zéro répertoire ou plus.
logs/*day/debug.log logs/monday/debug.log
logs/tuesday/debug.log
mais pas
logs/latest/debug.log
Des caractères génériques peuvent également être utilisés dans les noms de répertoire.
logs/debug.log logs/debug.log
mais pas
debug.log
build/logs/debug.log
Les modèles indiquant un fichier dans un répertoire spécifique dépendent de la racine du dépôt. (Vous pouvez préfixer une barre oblique si vous le souhaitez, mais cela n'a aucun effet particulier.)

** Ces explications supposent que votre fichier .gitignore se trouve dans le répertoire de niveau supérieur de votre dépôt, comme le veut la convention. Si votre dépôt contient plusieurs fichiers .gitignore, remplacez mentalement la « racine du dépôt » par le « répertoire contenant le fichier .gitignore » (et pensez à les rassembler, pour la santé mentale de votre équipe). *

Outre ces caractères, vous pouvez utiliser # pour inclure des commentaires dans votre fichier .gitignore :

# Ignorez tous les logs
*.log

Vous pouvez utiliser \ pour ignorer les caractères de modèle .gitignore si certains fichiers ou répertoires en contiennent :

# Ignorez le fichier appelé foo[01].txt
foo\[01\].txt

Fichiers .gitignore partagés dans votre dépôt

Les règles ignore de Git sont généralement définies dans un fichier .gitignore à la racine de votre dépôt. Toutefois, vous pouvez décider de définir plusieurs fichiers .gitignore dans différents répertoires de votre dépôt. Chaque modèle d'un fichier .gitignore spécifique est testé par rapport au répertoire contenant ce fichier. Toutefois la convention, et l'approche la plus simple, consiste à définir un fichier .gitignore unique à la racine. Lorsque votre fichier .gitignore est vérifié, il est contrôlé comme tout autre fichier de votre dépôt et partagé avec les membres de votre équipe lorsque vous faites un push. Généralement, vous ne devez inclure dans le fichier .gitignore que des modèles intéressants pour les autres utilisateurs du dépôt.

Règles personnelles pour ignorer des éléments dans Git

Vous pouvez également définir des modèles ignore personnels pour un dépôt spécifique dans un fichier spécial : .git/info/exclude. Ce fichier n'est pas contrôlé, ni distribué dans votre dépôt, vous pouvez donc parfaitement y inclure des modèles qui ne seront probablement intéressants que pour vous. Par exemple, si vous disposez d'une configuration de journalisation personnalisée ou d'outils de développement spéciaux qui génèrent des fichiers dans le répertoire de travail de votre dépôt, vous pouvez les ajouter à .git/info/exclude pour les empêcher d'être accidentellement commités vers votre dépôt.

Règles générales pour ignorer des éléments dans Git

En outre, vous pouvez définir des modèles Git ignore globaux pour tous les dépôts de votre système local en définissant la propriété Git core.excludesFile. Vous devrez créer ce fichier vous-même. Si vous hésitez sur l'emplacement de votre fichier .gitignore global, votre répertoire de base n'est pas un mauvais choix (et permet des recherches plus simples par la suite). Une fois le fichier créé, vous devrez configurer son emplacement avec git config :

$ touch ~/.gitignore
$ git config --global core.excludesFile ~/.gitignore

Soyez attentifs aux modèles que vous choisissez d'ignorer globalement, étant donné que différents types de fichiers sont pertinents pour différents projets. Les fichiers de système d'exploitation spéciaux (par ex., .DS_Store et thumbs.db) ou les fichiers temporaires créés par certains outils de développement sont très souvent ignorés globalement.

Ignorer un fichier commité au préalable

Si vous souhaitez ignorer un fichier que vous avez commité par le passé, vous devrez supprimer le fichier de votre dépôt avant d'ajouter une règle .gitignore pour ce dernier. Si vous utilisez l'option --cached avec git rm, le fichier sera supprimé de votre dépôt, mais demeurera dans votre répertoire de travail en tant que fichier ignoré.

$ echo debug.log >> .gitignore
$ git rm --cached debug.log
rm 'debug.log'
$ git commit -m "Start ignoring debug.log"

Vous pouvez omettre l'option --cached si vous souhaitez supprimer le fichier du dépôt et de votre système de fichiers local.

Commiter un fichier ignoré

Il est possible de forcer le commit d'un fichier ignoré dans le dépôt à l'aide de l'option -f (ou --force) avec git add :

$ cat .gitignore
*.log
$ git add -f debug.log
$ git commit -m "Force adding debug.log"

Vous pouvez envisager de le faire si vous avez défini un modèle général (comme *.log), mais que vous voulez commiter un fichier spécifique. Cependant, une meilleure solution consiste à définir une exception à la règle générale :

$ echo !debug.log >> .gitignore
$ cat .gitignore
*.log
!debug.log
$ git add debug.log
$ git commit -m "Adding debug.log"

Cette approche est plus claire, et moins perturbante pour les membres de votre équipe.

Stasher un fichier ignoré

git stash est une puissante fonctionnalité Git qui permet de mettre temporairement en pause et de restaurer des changements locaux, afin de les réutiliser plus tard. Comme vous vous en doutez, git stash fait par défaut l'impasse sur les fichiers ignorés et ne stashe que les changements apportés aux fichiers trackés par Git. Cependant, vous pouvez appeler git stash avec l'option --all pour stasher des changements dans les fichiers ignorés et non trackés.

Déboguer des fichiers .gitignore

Si vous avez des modèles .gitignore compliqués ou des modèles répartis sur plusieurs fichiers .gitignore, il peut être difficile de déterminer la raison pour laquelle un fichier spécifique est ignoré. Vous pouvez utiliser la commande git check-ignore avec l'option -v (ou --verbose) pour déterminer le modèle à cause duquel un fichier spécifique est ignoré :

$ git check-ignore -v debug.log
.gitignore:3:*.log debug.log

La sortie indique :

<fichier contenant le modèle> : <numéro de ligne du modèle> : <modèle> <nom_fichier>

Si vous le souhaitez, vous pouvez transmettre plusieurs noms de fichiers à git check-ignore, et les noms eux-mêmes ne doivent pas nécessairement correspondre aux fichiers présents dans votre dépôt.

Prêt à découvrir Git ?

Essayez ce tutoriel interactif.

Démarrez maintenant