Générateur de .gitignore
Créez un fichier .gitignore en cochant les langages, frameworks et éditeurs que vous utilisez — Node.js, Python, Java, macOS, Windows, VS Code et bien d'autres — dédupliqué et prêt à télécharger.
229 vues
Comment ça marche
Cochez les cases correspondant à votre projet — un langage ou environnement d'exécution comme Node.js, Python ou Java, un système d'exploitation comme macOS, Windows ou Linux, un éditeur comme VS Code ou IntelliJ/JetBrains, ainsi qu'un bloc pour les fichiers résiduels propres à Git et un bloc pour .env et les secrets. Chaque case ajoute un petit ensemble de règles d'exclusion bien établies, tirées des conventions réellement utilisées par la communauté — node_modules/ pour Node, __pycache__/ et .venv/ pour Python, *.class et target/ pour Java, .DS_Store pour macOS, Thumbs.db pour Windows, et ainsi de suite. À mesure que vous cochez des cases, l'outil fusionne le tout en une seule liste, supprime les doublons exacts et affiche le résultat en direct dans une zone de texte que vous pouvez copier ou télécharger directement sous forme de fichier nommé .gitignore.
L'intérêt de combiner les catégories plutôt que d'en écrire une à la main est que la plupart des projets réels relèvent de plusieurs catégories à la fois : une API Node.js développée sur un Mac avec VS Code a besoin du bloc Node pour les fichiers de build, du bloc macOS pour que .DS_Store ne se glisse jamais dans une pull request, et du bloc VS Code pour que vos réglages d'éditeur personnels n'écrasent pas ceux d'un collègue. Cocher les trois cases et télécharger en une seule fois est plus rapide et moins risqué que d'assembler des règles de mémoire ou de copier des fragments provenant d'anciens projets.
Ce qu'il faut savoir
Un fichier .gitignore n'affecte que les fichiers que Git ne connaît pas encore — il indique à Git quels fichiers non suivis exclure de git status, git add . et des futurs commits. Il n'a aucun effet sur les fichiers déjà suivis (déjà commités au moins une fois). C'est la confusion la plus fréquente : ajouter .env au .gitignore après qu'il a déjà été commité ne le retire pas du dépôt et n'empêche pas Git de suivre ses modifications futures. Pour réellement cesser de suivre un fichier, il faut d'abord exécuter git rm --cached <fichier> (ce qui le retire de l'index de Git tout en le laissant sur le disque), commiter cette suppression, et c'est seulement à ce moment-là que la règle .gitignore correspondante prend effet pour la suite.
La plupart des règles proposées ici s'appuient sur le dépôt officiel github/gitignore de GitHub, la référence la plus largement utilisée pour les modèles spécifiques à un langage ou un outil, et la même collection que GitHub propose lui-même lors de la création d'un nouveau dépôt via son interface web. Garder les dossiers de dépendances comme node_modules/ et les résultats de build comme dist/ ou target/ hors du contrôle de version est important pour la taille du dépôt — ces dossiers peuvent facilement peser plusieurs fois plus lourd que votre code source réel et se régénèrent trivialement à partir d'un fichier de verrouillage ou d'un script de build — tandis qu'exclure des fichiers comme .env, *.pem et *.key est important pour la sécurité : commiter un secret dans l'historique Git le rend pratiquement public pour toujours, car le supprimer du dernier commit ne l'efface pas des commits précédents sans réécrire entièrement l'historique.
Questions fréquentes
J'ai ajouté un fichier à .gitignore mais Git continue de le suivre — pourquoi ?
.gitignore empêche seulement Git de suivre les fichiers qu'il ne connaît pas encore. Si le fichier a été commité avant l'ajout de la règle, Git continue de le suivre quoi que dise .gitignore. Corrigez cela avec git rm --cached <fichier> (ou git rm -r --cached <dossier> pour un dossier), puis commitez ce changement — à partir de là, la règle .gitignore prend effet.
Puis-je combiner plusieurs catégories, comme Node.js, macOS et VS Code ensemble ?
Oui — c'est le cas normal. Cochez toutes les cases correspondant à votre configuration et l'outil fusionne toutes les règles obtenues en une seule liste, en supprimant les doublons exacts pour qu'une même ligne n'apparaisse jamais deux fois.
D'où viennent ces règles d'exclusion ?
Elles suivent les mêmes conventions que le dépôt officiel de modèles github/gitignore de GitHub, la référence standard vers laquelle pointent la plupart des outils et tutoriels. Ce sont les mêmes règles de fichiers et dossiers que vous obtiendriez en générant un modèle via l'option « Add .gitignore » de GitHub lors de la création d'un dépôt.
Pourquoi node_modules/ ou .env ne doivent-ils jamais être commités ?
node_modules/ est un cache de dépendances régénérable en quelques secondes à partir de package.json/package-lock.json — le commiter gonfle le dépôt de mégaoctets, parfois de gigaoctets, de fichiers redondants. .env est différent : il contient généralement des clés API, des mots de passe de base de données ou d'autres secrets, et dès qu'un secret entre dans l'historique Git, il doit être considéré comme compromis, car le supprimer du dernier commit ne le retire pas des commits précédents — seule une réécriture de l'historique, accompagnée d'une rotation du secret, corrige réellement le problème.
Le fichier téléchargé doit-il être renommé ?
Non. Le bouton de téléchargement enregistre le fichier avec exactement le nom attendu par Git — .gitignore, avec un point en tête et sans extension — vous pouvez donc le placer directement à la racine de votre projet, avant votre premier commit.
Outils similaires
Signaler un problème
Générateur de .gitignore
Commentaires
Pas encore de commentaires — soyez le premier à en écrire un !