CHEMINS ET RÈGLES GIT
Un fichier .gitignore racine et des chemins à vérifier. Un / final désigne un dossier.
Les règles et chemins restent dans ce navigateur. Aucun dépôt n’est lu ni modifié.
Saisissez au moins un chemin.
Indiquez des chemins relatifs au dossier de ce .gitignore, séparés par /. Terminez les dossiers par /. Chemins absolus, lettres de lecteur, antislashs, segments vides, . et .. sont refusés. Les espaces sont conservés.
Simulation de chemins non suivis avec un seul .gitignore racine. Comparaison des octets UTF-8 sensible à la casse ; aucun fichier imbriqué, exclusion globale, index ou accès au disque.
50 lignes physiques de règles, 200 chemins non vides ; 256 unités UTF-16 par règle, 512 par chemin, 32 segments. Caractères de contrôle refusés. Arrêt du worker après 2 secondes.
Résultats périmés ou calcul en cours.
Une exception peut désigner exactement le bon fichier sans le rétablir : son dossier parent est parfois déjà exclu. Ce Testeur de .gitignore montre la règle décisive et le parent responsable pour distinguer ces deux situations.
Les deux champs contiennent un exemple au démarrage. Remplacez-le par vos règles gitignore et vos chemins de fichiers : chaque résultat indique une exclusion, une réintégration explicite ou une absence de règle, avec un historique complet.
Avec build/, le dossier est exclu avant l’examen de build/keep.txt : !build/keep.txt ne suffit donc pas. À l’inverse, cache/* permet de parcourir cache/ et !cache/keep.txt peut réintégrer le fichier. Le Testeur de .gitignore indique quel ancêtre bloque réellement la négation.
Une exclusion, puis une exception, puis une autre exclusion peuvent inverser deux fois le résultat. L’historique recalcule le préfixe complet après chaque ligne physique, même vide ou commentée. La règle décisive affichée peut venir d’une ligne antérieure, notamment si elle exclut un parent.
Les chemins partent du dossier contenant le .gitignore testé. Saisissez build/ pour un dossier, build pour un fichier. Le / initial ancre une règle, mais n’est pas accepté dans un chemin candidat. Les espaces d’un nom sont significatifs et restent intacts.
Ouvrez l’historique du chemin et recherchez le parent bloquant. Il faut réintégrer ce dossier ou exclure seulement ses enfants avec cache/*, par exemple. Une exception sur un enfant ne peut pas franchir un parent exclu ; observez la ligne décisive de chaque étape.
Le mode automatique attend 350 ms après une modification. Désactivez-le pour lancer le test avec le bouton ou Ctrl/Cmd+Entrée. Toute modification périme le rapport. Exemple et Effacer présentent un aperçu ; Rétablir restaure champs et résultats. Le JSON conserve l’historique.
Le moteur ignore 7.0.9 traite *, ?, les classes entre crochets et **. La comparaison porte sur les octets UTF-8 et distingue les majuscules : ? représente un octet, pas nécessairement un caractère complet. Ni développement des accolades ni mode expression régulière supplémentaire.
Les commentaires et lignes vides gardent leur numéro. Pour chaque nœud accessible, la dernière règle correspondante détermine l’exclusion ou la réintégration. Deux exclusions identiques font donc apparaître la dernière ligne correspondante, pas seulement la première.
Le JSON contient chemins originaux, texte des règles et toutes les étapes. Le TSV résume le type de chemin, son état, sa ligne décisive, son motif et son parent bloquant. Toutes les lignes sont exportées, même si seules 50 sont visibles. Une apostrophe protège les cellules TSV ressemblant à une formule.
Un dossier exclu empêche Git d’examiner ses enfants. Réintégrez d’abord le parent, ou remplacez son exclusion par un motif visant ses enfants, par exemple build/*, puis ajoutez l’exception. Le Testeur de .gitignore affiche le parent bloquant avec sa règle décisive.
Placez-le à la racine du dépôt pour les règles communes, ou dans un sous-dossier pour des règles locales à ce sous-arbre. Les motifs sont relatifs au dossier du fichier. Ici, un seul .gitignore est simulé : saisissez tous les chemins depuis sa base.
Ajouter une règle ne retire pas un fichier de l’index. Vérifiez d’abord son état avec Git. Si vous souhaitez cesser de le suivre tout en gardant la copie locale, examinez git rm --cached sur le chemin concerné, puis validez le retrait de l’index. Le testeur ne modifie rien dans votre dépôt.
Oui, les règles communes au projet ont leur place dans un .gitignore versionné pour être partagées. Les préférences propres à votre environnement peuvent aller dans un fichier global ou .git/info/exclude. Ce choix évite d’imposer vos fichiers temporaires personnels à toute l’équipe.
Pour les fichiers personnels qui reviennent dans plusieurs dépôts, comme ceux d’un éditeur. Git peut lire un fichier défini par core.excludesFile. Les règles propres au projet restent dans son .gitignore ; ce testeur ne combine pas les exclusions globales avec le texte saisi.
Un cas de chemin à nous signaler ?
Essayez le Testeur de .gitignore avec un chemin à exclure et un autre à conserver. Ajoutez aussi le dossier parent quand une exception semble sans effet.
Joignez l’historique exporté à votre revue, puis confirmez le résultat avec Git dans le dépôt concerné.