Créez un .gitignore à partir de 61 modèles pour langages, frameworks, éditeurs et systèmes
Fonctionne dans votre navigateur. Rien de ce que vous saisissez n'est envoyé nulle part. Vérifié le 16 octobre 2026.Un fichier .gitignore liste les fichiers que git doit laisser non suivis, un motif par ligne. Choisissez les modèles de votre stack, comme Node.js, macOS et VS Code, parmi 61 modèles officiels github/gitignore ; ils sont fusionnés en un seul fichier que vous copiez ou téléchargez, et tout chemin peut être testé contre les règles avant le commit.
Cette page a été traduite automatiquement à partir de l'original anglais. Aucune personne n’a encore relu la traduction : c’est la version anglaise qui fait foi. Lire l'original en anglais
Touchez les modèles de votre projet, comme Node.js, macOS et VS Code, ou recherchez-en un par son nom.
Ajoutez vos propres lignes, comme *.pem ou scratch/, dans la zone Vos propres règles.
Saisissez quelques chemins sous Tester des chemins pour voir lesquels git ignorera et quelle règle en décide.
Cliquez sur Copier ou Télécharger, puis enregistrez le fichier sous le nom .gitignore dans le dossier racine du dépôt.
Tout nouveau dépôt a besoin d'un .gitignore avant le premier commit, sinon les sorties de build, les dépendances et les réglages de l'éditeur finissent dans l'historique. GitHub publie un modèle par langage, framework, éditeur et système d'exploitation ; cette page en propose 61, à un commit fixe, et fusionne ceux que vous touchez en un seul fichier.
Fusionner sans surprise. Les modèles se recoupent : Node.js, Next.js et NestJS ignorent tous les logs. Une ligne répétée n'est supprimée que si aucune règle ! ne se trouve entre les deux copies, de sorte que le fichier fusionné ignore exactement ce que les modèles ignorent l'un après l'autre. La page indique combien de lignes elle a supprimées.
Tester des chemins. Saisissez des chemins sous Tester des chemins, un par ligne, avec une barre oblique à la fin d'un dossier. Chacun est marqué ignoré ou conservé, avec le numéro de ligne et la règle qui a décidé. La correspondance suit les règles de git lui-même :
| Motif | Correspond à | Ne correspond pas à |
|---|---|---|
*.log |
debug.log, logs/app.log |
log.txt |
build/ |
le dossier build à n'importe quelle profondeur |
un fichier nommé build |
/dist |
dist à la racine uniquement |
src/dist |
doc/*.txt |
doc/a.txt |
doc/sub/a.txt |
**/secrets/** |
api/secrets/key.pem |
secrets lui-même |
!keep.log |
réintègre keep.log |
un fichier dans un dossier ignoré |
Un fichier dans un dossier ignoré reste ignoré. Git ne regarde pas à l'intérieur d'un dossier ignoré, donc !secret/ok.txt après secret/ n'a aucun effet. Écrivez plutôt secret/*, et la ligne ! fonctionne.
Fichiers déjà suivis. Un .gitignore n'affecte que les fichiers non suivis. Si un fichier a déjà été commité, retirez-le de l'index avec git rm --cached puis commitez ; le fichier reste sur votre disque.
Le testeur de chemins a été vérifié contre git check-ignore sur plus de 1 000 chemins, avec des jeux de règles écrits à la main et de vrais modèles. Tout s'exécute dans votre navigateur ; rien de ce que vous saisissez n'est envoyé nulle part.
Enregistrez-le sous le nom .gitignore, avec le point initial et sans extension, dans le dossier racine du dépôt, à côté du dossier .git. Les motifs avec une barre oblique au début ou au milieu sont lus depuis ce dossier. Un .gitignore dans un sous-dossier fonctionne aussi et ne s'applique qu'en dessous.
Un .gitignore n'affecte que les fichiers que git ne suit pas encore. Une fois un fichier commité, git continue de le suivre. Exécutez git rm --cached suivi du chemin, commitez, et la règle s'applique dès lors. Le fichier reste sur votre disque ; seule sa copie dans l'index disparaît.
Ignorez le contenu du dossier plutôt que le dossier : écrivez logs/* puis !logs/keep.txt. Si vous écrivez logs/ à la place, git saute tout le dossier sans regarder dedans, et la ligne ! ne peut jamais réintégrer le fichier. La zone Tester des chemins montre dans quel cas vous êtes.
Une barre oblique à la fin limite le motif aux dossiers, donc build/ ignore un dossier nommé build mais pas un fichier. Une barre oblique au début ou au milieu lie le motif au dossier du .gitignore, donc /dist ignore uniquement le dist de la racine. Sans barre oblique, le motif correspond à n'importe quelle profondeur.
Oui. Les 61 textes proviennent sans modification du dépôt github/gitignore à un commit fixe, la collection que GitHub utilise lorsque vous créez un dépôt, publiée sous licence CC0. Chaque bloc du résultat porte en en-tête le nom du modèle, pour que vous voyiez d'où vient une règle.
Oui, comme git sous Linux et dans la plupart des systèmes de CI, donc Build/ ne correspond pas à un dossier nommé build. Sous Windows et macOS, git règle généralement core.ignorecase sur true et ignore la casse, si bien qu'un motif peut correspondre en local mais pas sur le serveur de build. Écrivez les motifs avec la casse exacte des fichiers.
Les taux et les règles changent ; vérifiez la source avant de vous fier à un chiffre.
Toujours bloqué ? Poser une question sur Générateur de .gitignore et toute personne qui connaît la réponse peut répondre. Aucun compte nécessaire.