Générateur de .gitignore
Cochez un ou plusieurs modèles (langages, frameworks, systèmes, éditeurs) : le fichier .gitignore combiné et dédupliqué se met à jour en direct.
Modèles (3 sélectionnés)
Langages
Frameworks
Outils
Systèmes
Éditeurs
À quoi sert un fichier .gitignore ?
Un fichier .gitignore liste les motifs de chemins que Git ne doit ni suivre ni proposer à la validation : dépendances installées (node_modules/), artefacts de build, secrets locaux (.env), fichiers générés par le système d'exploitation ou l'éditeur. Il garde l'historique lisible, les diffs utiles et évite qu'un mot de passe local se retrouve poussé sur le dépôt distant.
Comment Git applique les règles
Git compare chaque chemin non suivi à l'ensemble des motifs, et c'est la dernière règle correspondante qui l'emporte : l'ordre des lignes compte. Une exception écrite avec ! doit donc figurer après la règle qu'elle annule. Un piège subsiste : si un répertoire entier est exclu, Git n'y descend pas et aucune négation ne peut réintégrer un fichier situé à l'intérieur — il faut d'abord désexclure le répertoire (dossier/* puis !dossier/garder.txt).
| Motif | Effet |
|---|---|
| build/ | La barre oblique finale restreint la règle aux répertoires : un fichier nommé build reste suivi. |
| *.log | Tous les fichiers .log, à n'importe quelle profondeur du dépôt. |
| /config.local | La barre oblique initiale ancre la règle au dossier du .gitignore : un config.local situé dans un sous-dossier n'est pas ignoré. |
| doc/*.pdf | Une barre oblique au milieu ancre aussi la règle : elle ne vise que doc/ à ce niveau. L'astérisque ne traverse jamais une barre oblique. |
| **/tmp | Deux astérisques traversent les répertoires : tout dossier ou fichier tmp, où qu'il soit. |
| !important.log | Le point d'exclamation réintègre un fichier exclu par une règle précédente. |
| # commentaire | Ligne ignorée. Une règle commençant vraiment par # s'écrit \#. |
| temp?.txt | Le point d'interrogation remplace un caractère unique ; [0-9] accepte une classe de caractères. |
Pourquoi un fichier déjà suivi n'est pas ignoré
C'est la confusion la plus fréquente, et elle n'est pas un bogue : le .gitignore ne s'applique qu'aux fichiers non suivis. Dès qu'un fichier a été ajouté à l'index une seule fois, Git continue d'en signaler les modifications quelle que soit la règle ajoutée ensuite. La correction tient en une commande — git rm --cached chemin/du/fichier — qui retire le fichier du suivi sans l'effacer du disque ; il faut ensuite valider cette suppression. Pour repartir proprement sur tout un dépôt après avoir remanié les règles :
git rm -r --cached .
git add .
git commit -m "Applique le nouveau .gitignore" Attention : cesser de suivre un fichier ne l'efface pas de l'historique. Un .env validé par erreur reste consultable dans les commits passés, y compris chez ceux qui ont déjà cloné le dépôt. Le réflexe correct est de révoquer la clé concernée, pas seulement de la retirer du suivi.
Parce que Git le suit déjà. Le .gitignore ne concerne que les fichiers non suivis : un fichier ajouté à l'index avant l'écriture de la règle continue d'être versionné indéfiniment. Retirez-le du suivi sans l'effacer du disque avec git rm --cached chemin/du/fichier, puis validez. Pour tout un dépôt : git rm -r --cached . suivi de git add . et d'un commit.
La commande git check-ignore -v chemin/du/fichier affiche le fichier de règles, le numéro de ligne et le motif exact qui s'applique. C'est le moyen le plus rapide de trancher entre une règle trop large et un fichier déjà suivi. Sans sortie, aucune règle ne correspond.
Non. Ajouter la règle empêche les prochains ajouts, mais le contenu déjà validé reste dans l'historique du dépôt et reste lisible par toute personne y ayant accès, même après suppression du fichier. Considérez le secret comme compromis : révoquez-le et régénérez-le, puis nettoyez éventuellement l'historique avec git filter-repo.
Collez le contenu dans un fichier nommé exactement .gitignore (avec le point, sans extension) à la racine de votre dépôt Git. Un dépôt peut aussi contenir des .gitignore dans des sous-dossiers, dont les règles s'appliquent à partir de leur emplacement. Pour des exclusions personnelles à ne pas partager, utilisez plutôt .git/info/exclude, ou un fichier global déclaré via core.excludesFile.
Le résultat combiné est dédupliqué : si une règle (par exemple node_modules/) apparaît dans plusieurs modèles sélectionnés, elle n'est écrite qu'une seule fois, dans la section du premier modèle où elle apparaît.
Non. Il n'y a rien à envoyer : les modèles .gitignore sont intégrés directement dans la page, et la combinaison se fait entièrement dans votre navigateur, en JavaScript. Aucune donnée ne quitte votre appareil.