Close

Git ignore

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

Exemples de correspondances

logs/debug.log
logs/monday/foo.bar
build/logs/debug.log

Explication*

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

Exemples de correspondances

logs/debug.log
build/logs/debug.log
but not
logs/build/debug.log

Explication*

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

Exemples de correspondances

debug.log
foo.log
.log
logs/debug.log

Explication*

Un astérisque est un caractère générique qui correspond à zéro caractère ou plus.

*.log
!important.log

Exemples de correspondances

debug.log
but not
logs/debug.log

Explication*

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é.

/debug.log

Exemples de correspondances

debug.log
but not
logs/debug.log

Explication*

Les modèles définis après un modèle invalidant ignoreront à nouveau tout fichier invalidé au préalable.

debug.log

Exemples de correspondances

debug.log
logs/debug.log

Explication*

Préfixer une barre oblique associe uniquement des fichiers dans la racine du dépôt.

debug?.log

Exemples de correspondances

debug0.log
debugg.log
but not
debug10.log

Explication*

Un point d'interrogation correspond exactement à un caractère.

debug[0-9].log

Exemples de correspondances

debug0.log
debug1.log
but not
debug10.log

Explication*

Vous pouvez également utiliser des crochets pour faire correspondre un caractère unique d'une plage spécifique.

debug[01].log

Exemples de correspondances

debug0.log
debug1.log
but not
debug2.log
debug01.log

Explication*

Les crochets correspondent à un caractère unique de l'ensemble spécifié.

debug[!01].log

Exemples de correspondances

debug2.log
but not
debug0.log
debug1.log
debug01.log

Explication*

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

Exemples de correspondances

debuga.log
debugb.log
but not
debug1.log

Explication*

Les plages doivent être numériques ou alphabétiques.

logs

Exemples de correspondances

logs
logs/debug.log
logs/latest/foo.bar
build/logs
build/logs/debug.log

Explication*

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/

Exemples de correspondances

logs/debug.log
logs/latest/foo.bar
build/logs/foo.bar
build/logs/latest/debug.log

Explication*

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

Exemples de correspondances

logs/debug.log
logs/important.log

Explication*

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

Exemples de correspondances

logs/debug.log
logs/monday/debug.log
logs/monday/pm/debug.log

Explication*

Une double astérisque correspond à zéro répertoire ou plus.

logs/*day/debug.log

Exemples de correspondances

logs/monday/debug.log
logs/tuesday/debug.log
but not
logs/latest/debug.log

Explication*

Des caractères génériques peuvent également être utilisés dans les noms de répertoire.

logs/debug.log

Exemples de correspondances

logs/debug.log
but not
debug.log
build/logs/debug.log

Explication*

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 :

# ignore all logs
*.log

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

# ignore the file literally named foo[01].txt
foo\[01\].txt
branche git
Ressource connexe

branche git

Logo Bitbucket
DÉCOUVRIR LA SOLUTION

Découvrir Git avec Bitbucket Cloud

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 :

<file containing the pattern> : <line number of the pattern> : <pattern>    <file name>

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.


Partager cet article
Thème suivant

Lectures recommandées

Ajoutez ces ressources à vos favoris pour en savoir plus sur les types d'équipes DevOps, ou pour les mises à jour continues de DevOps chez Atlassian.

Des personnes qui collaborent à l'aide d'un mur rempli d'outils

Le blog Bitbucket

Illustration DevOps

Parcours de formation DevOps

Démos Des démos avec des partenaires d'Atlassian

Fonctionnement de Bitbucket Cloud avec Atlassian Open DevOps

Inscrivez-vous à notre newsletter DevOps

Thank you for signing up