Aller au contenu principal

Générateur de .gitignore

Sélectionnez les environnements utilisés dans votre projet, ajoutez vos règles personnalisées et générez un fichier .gitignore propre sans doublons.

  • Presse-papiers
  • Export

Intégrer ce widget

Personnalisez le rendu, vérifiez l’aperçu puis copiez le code.

Aperçu

Type de code d’intégration

Code à copier

Responsive et redimensionné automatiquement par Bethemesh.

Modèles à inclure

Sélectionnez uniquement les technologies réellement utilisées par votre projet.

Une règle par ligne. L’ordre et les répétitions des règles personnalisées sont conservés.

Fichier .gitignore généré

Cet outil vous a-t-il été utile ?

Comment fonctionne cet outil ?

Composez un fichier .gitignore pour les technologies de votre dépôt en combinant des modèles locaux et vos propres motifs. Le générateur produit du texte à relire puis à placer dans le projet ; il n’ouvre pas votre dépôt et ne change pas l’index Git. Il convient notamment aux dossiers de dépendances, sorties de compilation et caches. Choisissez les exclusions selon les fichiers réellement générés chez vous : un modèle utile ailleurs peut masquer un fichier nécessaire à votre équipe.

Les modèles sélectionnés sont assemblés dans l’ordre du catalogue. Le générateur supprime les motifs exactement identiques entre modèles, mais ne cherche pas à simplifier les recouvrements entre *.log et un chemin précis. Les règles personnalisées sont ajoutées à la fin, dans leur ordre d’origine. Leurs répétitions sont conservées, car un motif répété après une négation peut changer le résultat. Les barres obliques inverses et espaces échappés sont préservés.

Git interprète les motifs selon leur emplacement. Un / initial ancre à l’emplacement du fichier .gitignore ; un / final vise un répertoire. * et ** n’ont pas toujours la même portée. ! réinclut un chemin précédemment exclu, mais Git ne peut pas réinclure un fichier situé dans un répertoire parent entièrement ignoré. Un # initial démarre un commentaire ; échappez-le si le nom du fichier commence réellement par ce caractère.

Le modèle d’environnement ignore .env et .env.* puis réinclut !.env.example pour permettre de versionner un exemple sans secrets. Les règles affectent principalement les fichiers non suivis. Un fichier déjà présent dans l’index reste suivi, même s’il correspond à un nouveau motif. Le générateur ne retire aucun fichier de l’index, ne nettoie pas l’historique et ne constitue pas une recherche de secrets.

Comment utiliser cet outil ?

  1. Sélectionner les modèles utiles

    Cochez les environnements réellement présents. Évitez de sélectionner toutes les technologies par habitude, car certaines exclusions peuvent être trop larges.

  2. Ajouter les motifs spécifiques

    Saisissez une règle par ligne et placez les négations après les exclusions concernées. Les commentaires de section peuvent être activés ou désactivés.

  3. Vérifier avec Git

    Téléchargez .gitignore, relisez-le puis contrôlez un chemin avec git check-ignore -v. Vérifiez séparément les fichiers déjà suivis avant d’envisager une modification de l’index.

Cas d'utilisation

Démarrer un dépôt Node.js

Associez les dépendances Node aux sorties du framework utilisé, puis gardez le lockfile et la configuration nécessaires à une installation reproductible.

Partager un exemple d’environnement

Utilisez les motifs .env avec l’exception .env.example, puis vérifiez que ce fichier d’exemple ne contient que des valeurs fictives.

Fusionner des règles existantes

Ajoutez vos exceptions dans la section personnalisée et examinez leur ordre. Conservez une différence de texte pour voir précisément ce que vous allez remplacer.

Exemples

Préserver le fichier d’exemple

Avec les commentaires désactivés, le modèle environment produit trois lignes. L’exception arrive après les motifs d’exclusion pour garder .env.example visible.

Entrée

environment; includeComments=false

Résultat

.env
.env.*
!.env.example

Conserver un ordre significatif

Ces trois règles personnalisées restent dans cet ordre. La dernière exclusion peut annuler la réinclusion précédente ; supprimer le doublon changerait le sens.

Entrée

custom: *.log
!important.log
*.log

Résultat

*.log
!important.log
*.log

Conseils et bonnes pratiques

  • La suppression d’un secret du dernier état ne le retire pas de l’historique. Révoquez les identifiants exposés et traitez l’historique séparément.
  • Pour une exclusion personnelle d’éditeur, évaluez .git/info/exclude ou votre ignore global plutôt que d’imposer la règle à toute l’équipe.
  • Conservez les sources et la configuration de compilation nécessaires au projet ; exclure dist ne doit pas masquer les fichiers qui permettent de le reconstruire.

Sources et références

Questions fréquentes

Où placer le fichier généré ?

Généralement à la racine du dépôt. Git accepte aussi des .gitignore imbriqués, dont les motifs sont relatifs à leur répertoire. Adaptez les chemins si vous déplacez le fichier.

Pourquoi un fichier ignoré apparaît-il encore dans un commit ?

Il était peut-être déjà suivi. Les motifs ne retirent pas de l’index les fichiers existants ; examinez git ls-files et les changements préparés avant toute action.

Tous les doublons sont-ils supprimés ?

Les répétitions exactes entre modèles le sont. Les règles personnalisées gardent leurs répétitions et leur ordre pour respecter les exceptions introduites par !.

Le générateur garantit-il l’absence de secrets ?

Non. Il assemble des motifs sans analyser les fichiers ou leur historique. Une exclusion préventive complète une revue du dépôt, sans la remplacer.

Outils associés

Des outils similaires ou complémentaires à celui-ci.

Outils similaires

Comparez deux textes ligne par ligne et repérez rapidement les ajouts, suppressions et modifications.

DéveloppementMis en avantUtiliser l’outil

Convertissez les permissions Unix entre les notations octale et symbolique et générez une commande chmod.

DéveloppementUtiliser l’outil

Générez instantanément un ou plusieurs identifiants UUID v4 aléatoires prêts à copier.

DéveloppementMis en avantUtiliser l’outil