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
ouThumbs.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.
Dans ce document, nous aborderons :
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* |
---|---|---|
| Exemples de correspondances | 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. |
| Exemples de correspondances | 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. |
| Exemples de correspondances | Explication* Un astérisque est un caractère générique qui correspond à zéro caractère ou plus. |
| Exemples de correspondances | 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é. |
| Exemples de correspondances | Explication* Les modèles définis après un modèle invalidant ignoreront à nouveau tout fichier invalidé au préalable. |
| Exemples de correspondances | Explication* Préfixer une barre oblique associe uniquement des fichiers dans la racine du dépôt. |
| Exemples de correspondances | Explication* Un point d'interrogation correspond exactement à un caractère. |
| Exemples de correspondances | Explication* Vous pouvez également utiliser des crochets pour faire correspondre un caractère unique d'une plage spécifique. |
| Exemples de correspondances | Explication* Les crochets correspondent à un caractère unique de l'ensemble spécifié. |
| Exemples de correspondances | Explication* Un point d'exclamation peut être utilisé pour associer n'importe quel caractère, sauf ceux provenant de l'ensemble spécifié. |
| Exemples de correspondances | Explication* Les plages doivent être numériques ou alphabétiques. |
| Exemples de correspondances | 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 |
| Exemples de correspondances | 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é. |
| Exemples de correspondances | Explication* Attendez un peu. Ne faudrait-il pas annuler |
| Exemples de correspondances | Explication* Une double astérisque correspond à zéro répertoire ou plus. |
| Exemples de correspondances | Explication* Des caractères génériques peuvent également être utilisés dans les noms de répertoire. |
| Exemples de correspondances | 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
Ressource connexe
branche git
DÉCOUVRIR LA SOLUTION
Découvrir Git avec Bitbucket Cloud
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.