Générez des fichiers .gitignore propres et déterministes pour l'ensemble de votre stack en quelques secondes. Combinez les règles officielles, éliminez les doublons et téléchargez des configurations prêtes pour la production sans aucun pistage.
Gratuit · Génération dans le navigateur · Sans compte requis
# Created by https://dotgitignore.com
# Edit at https://dotgitignore.com/generator?select=node,nextjs,docker,macos
### Node ###
node_modules/
npm-debug.log*
yarn-debug.log*
yarn-error.log*
.pnpm-debug.log*
### Next.js ###
.next/
out/
build/
dist/
### Environment Variables ###
.env
.env*.local
!.env.example
### Docker ###
.docker/
*.tar
### Operating System (macOS) ###
.DS_Store
.AppleDouble
.LSOverrideExplorez des modèles préconfigurés avec des motifs d'exclusion vérifiés et le détail des règles.
Spécialement conçu pour les développeurs exigeant des fichiers de contrôle de version propres et déterministes :
Notre algorithme pur élimine les doublons exacts tout en respectant scrupuleusement l'ordre et les règles de négation (!motif).
Modèles officiels de GitHub enrichis de stacks modernes sélectionnés (Vite, Astro, Svelte, Claude Code).
Exécution 100% côté client en TypeScript. Vos choix et vos fichiers générés restent en mémoire locale et ne sont jamais transmis.
Une interface claire et sans distraction, avec support parfait des modes sombre et clair, sans lourdeurs SaaS.
Dans Git, les fichiers non suivis peuvent être involontairement inclus lors de la préparation d'un commit. Un fichier .gitignore indique précisément à Git quels fichiers, dossiers et motifs doivent être ignorés. Cela évite d'ajouter au dépôt des dépendances volumineuses, des identifiants secrets, des binaires compilés ou des caches locaux.
Les fichiers locaux comme .env, .env.local et vos clés privées SSH ne doivent jamais être commités pour éviter les fuites de sécurité.
Les dossiers gérés comme node_modules/, vendor/ ou les environnements virtuels Python (.venv/) alourdissent inutilement le dépôt et doivent être installés via des manifestes.
Les fichiers binaires et répertoires dist/, target/, *.class ou *.dll sont reproductibles à partir des sources et n'ont pas leur place dans l'historique Git.
Les architectures logicielles actuelles ne reposent presque jamais sur un outil unique. Une stack classique associe un langage d'exécution (Node.js ou Python), un framework (Next.js ou Spring Boot), des conteneurs (Docker), des outils de CI et des développeurs travaillant sous macOS, Windows ou Linux avec des éditeurs variés.
Un générateur de .gitignore vous permet de choisir chaque technologie de votre stack et de les regrouper en un fichier unique prêt pour la production. Plutôt que de copier-coller des extraits épars depuis des tutoriels — ce qui engendre souvent des doublons et des erreurs de syntaxe —, DotGitIgnore fusionne les règles de manière déterministe et produit un fichier propre à télécharger ou copier.
Suivez ces cinq étapes simples pour générer et déployer votre fichier .gitignore :
Recherchez ou sélectionnez vos technologies parmi plus de 321 modèles vérifiés dans le générateur.
Examinez les motifs catégorisés et le nombre de règles dans le visualiseur en direct.
Cliquez sur Copier pour placer le contenu dans le presse-papier ou sur Télécharger pour enregistrer le fichier.
Enregistrez le fichier à la racine de votre dépôt Git sous le nom exact .gitignore.
Si des fichiers avaient déjà été commités auparavant, exécutez git rm --cached pour cesser de les suivre.
Motifs représentatifs pour les langages et frameworks les plus populaires :
node_modules/ dist/ npm-debug.log* .env .env.local
__pycache__/ *.py[cod] .venv/ dist/ *.egg-info/
target/ *.class *.jar *.war .sts4-cache/
[Ll]ibrary/ [Tt]emp/ [Oo]bj/ [Bb]uild/ *.csproj
.terraform/ *.tfstate *.tfstate.* crash.log override.tf
*.pid docker-compose.override.yml .docker/ *.tar
Git applique une syntaxe de type glob pour faire correspondre les chemins des fichiers :
# commentLes lignes commençant par le caractère dièse # sont considérées comme des commentaires et ignorées par Git.
temp/Une barre oblique finale restreint la correspondance aux seuls répertoires, pas aux fichiers de même nom.
*.logUn astérisque correspond à zéro ou plusieurs caractères dans un même segment de chemin (ex. *.log).
/buildUne barre oblique initiale ancre le motif au répertoire racine où se trouve le fichier .gitignore.
**/logsUn double astérisque correspond de manière récursive aux répertoires à n'importe quel niveau de profondeur.
!important.logUn point d'exclamation annule une exclusion antérieure pour réinclure un fichier spécifiquement visé.
Tout ce que vous devez savoir sur la syntaxe, l'emplacement et la gestion des fichiers Git ignore.
Un fichier .gitignore est un fichier texte placé à la racine de votre dépôt Git. Il spécifie les fichiers et répertoires intentionnellement non suivis que Git doit ignorer, évitant ainsi de versionner les artefacts de compilation, les secrets locaux, les dossiers de dépendances et les fichiers temporaires.
Placez votre fichier .gitignore dans le répertoire racine de votre projet (par exemple, /mon-projet/.gitignore). À la racine, ses règles s'appliquent de manière récursive à tous les sous-dossiers. Vous pouvez également placer des fichiers .gitignore supplémentaires dans des sous-répertoires si des règles spécifiques s'y appliquent.
Oui. Les projets actuels combinent presque toujours plusieurs technologies (par exemple, Python + React + Docker + macOS + VS Code). DotGitIgnore vous permet de sélectionner autant de modèles que nécessaire, en éliminant automatiquement les doublons dans un fichier unique et propre.
Pour ignorer un dossier et l'ensemble de son contenu, ajoutez une barre oblique finale à son nom dans votre .gitignore (par exemple, node_modules/ ou build/). Sans barre oblique, le motif correspond aux fichiers et aux dossiers portant ce nom, alors que la barre oblique restreint la règle aux répertoires.
Ajouter un fichier à .gitignore ne le supprime pas de Git s'il a déjà été suivi dans des commits précédents. Pour arrêter de suivre un fichier existant sans l'effacer de votre disque dur, exécutez 'git rm --cached <fichier>' (ou 'git rm -r --cached <dossier>/' pour un répertoire), puis validez avec un commit.
Oui. La sortie générée par DotGitIgnore est du texte de configuration Git standard. Vous pouvez librement ajouter des chemins spécifiques, des variables locales, des commentaires ou adapter les règles directement dans le générateur ou dans votre éditeur après téléchargement.
Créez un fichier nommé .gitignore à la racine de votre dépôt, ajoutez les chemins relatifs ou motifs à exclure (comme dist/, .env ou *.log), et commitez-le avec 'git add .gitignore && git commit -m "Add .gitignore"'. Dès lors, Git ignorera les nouveaux fichiers non suivis correspondant à ces règles.
Lors de l'inspection de l'arbre de travail (par exemple, lors de 'git status' ou 'git add .'), Git compare les fichiers non suivis aux règles définies dans vos fichiers .gitignore. Si un chemin correspond à une règle et n'est pas réinclus par une négation ultérieure '!', Git l'exclut de l'indexation.
Un fichier .gitignore indique à Git quels fichiers non suivis doivent être exclus du contrôle de version. Il évite que les caches temporaires, les binaires compilés, les bibliothèques tierces, les fichiers système (.DS_Store) et les identifiants secrets ne soient envoyés par erreur sur les dépôts distants.
Oui. Dans la quasi-totalité des cas, le fichier .gitignore doit être versionné pour que tous les collaborateurs et les pipelines CI/CD partagent les mêmes règles d'exclusion. Pour vos préférences personnelles d'éditeur local, utilisez plutôt .git/info/exclude ou un fichier gitignore global.
La raison la plus fréquente est que le fichier est déjà suivi par Git. Le fichier .gitignore n'agit que sur les fichiers non suivis ; il ne supprime jamais un fichier déjà commité. Pour y remédier, retirez-le de l'index avec 'git rm --cached <fichier>' puis commitez. Une autre cause courante est une erreur de syntaxe dans le motif.
Si le fichier .gitignore a déjà été commité, s'ajouter lui-même n'a aucun effet car Git le suit déjà. Si vous l'ajoutez avant son premier commit, Git ignorera votre .gitignore, vous empêchant de le partager avec votre équipe. En pratique, il ne faut jamais ignorer le fichier .gitignore.
Vous pouvez tester si un fichier est ignoré en exécutant 'git check-ignore -v <chemin>'. Si le fichier est ignoré, Git affiche le fichier .gitignore source, le numéro de ligne et le motif correspondant. Vous pouvez également exécuter 'git status --ignored' pour afficher tous les fichiers exclus.
Créez votre fichier .gitignore avant votre tout premier commit, regroupez vos règles par catégories logiques (dépendances, compilation, secrets locaux), versionnez le fichier dans Git et gérez vos outils personnels dans votre gitignore global. DotGitIgnore vous assure de démarrer avec des règles propres et dédupliquées.
Incluez les dossiers de build (dist/, build/), les répertoires de dépendances (node_modules/, vendor/), les fichiers d'environnement (.env*), les fichiers binaires (*.class, *.o) et les journaux (*.log). N'ignorez jamais le code source, les fichiers d'exemple de configuration (.env.example) ou les fichiers lock de dépendances.
Oui. Git prend en charge plusieurs fichiers .gitignore dans l'arborescence des dossiers. Les règles d'un .gitignore situé dans un sous-dossier ne s'appliquent qu'à ce dossier et à ses sous-dossiers, prévalant sur les règles de la racine. C'est particulièrement utile dans les monorepos.
Pour ignorer un fichier où qu'il soit, inscrivez son nom dans le .gitignore (par exemple, secret.txt). Pour le restreindre à la racine du dépôt, préfixez-le d'une barre oblique (/secret.txt). Pour cibler un fichier imbriqué précis, indiquez son chemin relatif depuis la racine (config/credentials.json).
Ajoutez .env et ses variantes (.env.local, .env.*.local) à votre .gitignore pour empêcher la fuite de clés d'API et de mots de passe de base de données. Commitez toujours un fichier d'exemple comme .env.example avec des valeurs fictives pour informer l'équipe des variables nécessaires.
Le fichier .gitignore est suivi dans Git et partagé avec l'ensemble des contributeurs, ce qui est idéal pour les règles du projet (dépendances, builds). À l'inverse, .git/info/exclude est un fichier local stocké dans .git/ qui n'est jamais commité, parfait pour vos règles privées spécifiques à votre machine.
Le point d'exclamation (!) nie un motif pour réinclure un fichier qui avait été exclu par une règle précédente (par exemple, *.log suivi de !important.log). Notez que Git ne peut pas réinclure un fichier si son répertoire parent est déjà totalement ignoré.
Vous pouvez forcer Git à ajouter un fichier ignoré en utilisant l'option -f (ou --force) : 'git add -f chemin/vers/fichier'. Une fois commité, le fichier reste suivi par Git même s'il correspond à une règle du .gitignore, jusqu'à ce qu'il soit explicitement retiré avec 'git rm --cached'.
Combinez les modèles officiels, supprimez les règles en double et générez des configurations Git prêtes pour la production en quelques secondes.