Générateur de .gitignore

Qu'est-ce qu'un fichier .gitignore ?

Un fichier .gitignore indique à Git quels chemins exclure du contrôle de version. Il se trouve à la racine de votre dépôt et est lui-même versionné — chaque clone applique donc les mêmes règles. Sans ce fichier, vous finissez par suivre des binaires compilés, des dossiers de dépendances, des caches d'IDE, des fichiers de log et (le pire) des secrets comme les fichiers .env. Une fois ces éléments inscrits dans l'historique, ils peuvent y rester consultables indéfiniment, même après un push forcé, c'est pourquoi soigner le .gitignore dès le début d'un projet importe plus qu'on ne le pense. Ce générateur fusionne des motifs éprouvés pour les langages, frameworks, systèmes d'exploitation et éditeurs que vous utilisez réellement, puis déduplique les en-têtes pour conserver un fichier lisible. Il ne produit que des motifs de chemins — jamais de code source — il peut donc être déposé en toute sécurité dans un dépôt public. Si votre projet mélange un backend, un frontend, deux systèmes d'exploitation et trois éditeurs au sein de l'équipe, cochez-les tous : le résultat est un fichier unique, pas un dossier, et Git traite chaque ligne de manière additive. Vous pouvez le coller comme point de départ et l'ajuster ensuite.

Mode d'emploi

1. Choisissez vos modèles

Cliquez sur n'importe quelle puce dans les listes de langages, de systèmes d'exploitation ou d'éditeurs. Utilisez le champ de filtre en haut si la liste est longue — il correspond à la fois à l'étiquette et à la clé interne.

2. Vérifiez le résultat

Chaque modèle reçoit son propre en-tête de section commenté (# === Node.js ===) afin que vous puissiez identifier d'un coup d'œil l'origine de chaque règle. L'ordre suit celui de vos clics.

3. Copiez ou téléchargez

Copiez l'ensemble dans le presse-papiers, ou cliquez sur Télécharger pour l'enregistrer directement sous le nom .gitignore. Déposez-le à la racine de votre dépôt avant votre premier commit.

4. Ajustez selon vos besoins

Considérez le résultat comme un point de départ. Ajoutez les chemins propres à votre projet (téléversements, documentation générée, fichiers temporaires) à la fin, et supprimez toute règle qui ne s'applique pas à votre configuration.

Ce que fait chaque règle

Les motifs d'un .gitignore obéissent à des règles simples. Un chemin littéral comme node_modules/ ignore ce répertoire partout où il apparaît. Une barre oblique en tête (/dist) ancre le motif à la racine du dépôt. Les caractères glob fonctionnent comme prévu : *.log correspond aux fichiers par extension, **/cache est récursif, et les crochets comme *.[oa] correspondent à un ensemble de caractères. Un ! en tête annule une règle précédente, c'est ainsi qu'Unity conserve les fichiers .meta même lorsque leur cible est ignorée. Les lignes commençant par # sont des commentaires. Une barre oblique finale signifie « répertoire uniquement ». Les fichiers déjà suivis ne sont pas affectés — pour retirer un fichier du suivi après l'avoir ajouté au .gitignore, exécutez git rm --cached chemin.

Quand ajouter quoi

Choisissez les modèles de langage et framework pour les artefacts de compilation et les dossiers de dépendances (node_modules/, vendor/, target/). Ajoutez le modèle de système d'exploitation pour les systèmes utilisés par votre équipe — macOS laisse traîner des .DS_Store partout et Windows disperse des Thumbs.db. Ajoutez un modèle d'éditeur pour l'IDE retenu par l'équipe ; si chacun utilise le sien, ajoutez-les tous. Règle générale : au moins une stack + un OS + un éditeur pour tout nouveau dépôt. Évitez d'ignorer les fichiers de verrouillage (package-lock.json, composer.lock, Gemfile.lock) — ceux-ci doivent être versionnés pour garantir des builds reproductibles.

Questions fréquentes