Probador de patrones .gitignore｜Verifica qué regla realmente decide cada ruta

Pega tu archivo .gitignore y una lista de rutas para ver qué archivos quedan Ignorados o Mantenidos, con el número exacto de línea de la regla que produjo la decisión. Pensada para revisar cadenas de negación como *.log + !important.log, patrones de solo-directorio como node_modules/ y globs recursivos **/ antes de hacer commit de un cambio en .gitignore.

💡 Sobre esta herramienta

El archivo .gitignore esconde varias trampas que se notan tarde: el orden de las reglas decide el resultado final (gana la última coincidencia, no la primera), la barra final cambia el significado del patrón, y los globs con **/ pueden ser demasiado amplios o demasiado estrechos según lo que venga después. Ejecutar git check-ignore -v ruta por ruta funciona cuando ya sabes qué archivo investigar; pero después de editar un .gitignore de 50 líneas, lo útil es ver todas las consecuencias en paralelo.

Este probador toma el conjunto completo de reglas a la izquierda y la lista de rutas a la derecha, y muestra cada decisión junto con la regla que la produjo. Las reglas negadas se etiquetan con [negada], las de solo-directorio coinciden únicamente con rutas tipo carpeta, y los patrones inválidos aparecen en una franja roja arriba del resultado sin interrumpir la evaluación del resto.

🧐 Preguntas Frecuentes

P. ¿La precedencia es la misma que la de git? R. Sí: las reglas se evalúan de arriba hacia abajo y gana la última coincidencia. *.log seguido de !important.log mantiene important.log; en orden inverso lo ignora.

P. ¿Cómo funcionan los patrones de solo-directorio (node_modules/)? R. Las reglas que terminan en / solo coinciden con rutas tipo carpeta. Un archivo llamado node_modules (sin barra final) no entra. Una ruta como node_modules/lodash/index.js aparecerá como ignorada con la línea de la regla mostrada.

P. ¿Cómo se comportan los globs **/? R. **/foo coincide con foo a cualquier profundidad, foo/** con todo lo que cuelga de foo/. La especificación está en gitignore(5). Prueba **/build/ con a/build/x y a/b/build/y para confirmar.

P. ¿Qué pasa si un patrón tiene un error? R. Los patrones inválidos ([ sin cerrar, escapes mal formados) se listan en una franja roja arriba del resultado. La evaluación continúa con el resto de las reglas válidas.

P. ¿Puedo probar varios archivos .gitignore a la vez? R. El probador evalúa un único conjunto combinado. Si tienes un .gitignore raíz y otro en una subcarpeta, pégalos juntos en orden raíz → subcarpeta; las reglas más locales ganan al evaluarse al final.

P. ¿Por qué no coincide una ruta con / inicial? R. La barra / y el ./ iniciales se normalizan y se quitan del lado de la ruta. Para anclar a la raíz del repositorio, escribe el / del lado del patrón (por ejemplo /dist/).

📚 Detalles curiosos sobre .gitignore

El archivo .gitignore existe en git desde 2005, pero la gramática oficial vive en la página de manual gitignore(5), no en los README. Una sutileza que sorprende incluso a desarrolladores con experiencia: si un directorio padre ya está ignorado, ninguna regla !padre/hijo puede re-incluir un archivo dentro de él. Por eso el repositorio github/gitignore, que mantiene plantillas para Node, Python, Java, Unity y otros lenguajes, mantiene las reglas de negación cerca de las que pretenden sobreescribir y nunca dentro de una carpeta ya excluida.

Otra trampa que aparece a menudo en foros de habla hispana: git usa last-match-wins, no first-match-wins. Si copias una plantilla de github/gitignore y añades tus reglas propias al final, puedes re-ignorar sin querer algo que la plantilla des-ignoraba más arriba. Pasar el conjunto de reglas y un grupo de rutas por este probador antes del commit deja visible la cadena de override: cada fila de resultado dice exactamente qué línea decidió cada veredicto, así que un fallo se ve sin necesidad de correr git check-ignore archivo por archivo.