Generador de .gitignore
Genera tu .gitignore combinando 312 plantillas oficiales, con Bun, Tauri, Expo, NestJS y Cursor incluidas. Te explica qué ignora cada regla y prueba si una ruta queda fuera.
Qué hace esta herramienta
Eliges los lenguajes, frameworks, editores y sistemas operativos de tu proyecto y te devuelve un .gitignore listo para copiar, combinando las 312 plantillas oficiales de github/gitignore. Hasta ahí, lo que hace cualquier generador. Lo que aquí se añade son las dos cosas que faltaban:
- Te explica qué ignora cada regla. No un bloque de texto opaco que copias por fe, sino qué es
__pycache__, por qué.enves la línea más importante del archivo y qué implica la barra final debuild/. - Prueba una ruta concreta. Escribes
src/index.tsonode_modules/react/index.jsy te dice si quedaría ignorado y, sobre todo, qué regla lo decidió.
El catálogo está al día
Esto importa más de lo que parece. Los generadores veteranos del sector arrastran plantillas sin sincronizar desde hace años, así que si tu stack es reciente no lo encuentras. Aquí sí están:
Bun, Tauri, Expo, NestJS, Nix, OpenTofu, LangChain, Gleam, AWS CDK, y los editores y herramientas de la generación actual: Cursor, Zed, mise, Lefthook y los archivos de agentes.
El catálogo se vendoriza entero desde el repositorio oficial, que está bajo CC0 —dominio público—, y se refresca ejecutando un script. No hay llamadas a ningún servicio externo.
Cómo usarla
- Busca tu lenguaje, framework, editor o sistema operativo. Puedes elegir varios.
- Copia o descarga el
.gitignoregenerado. - Baja a Qué significa cada regla para entender lo que acabas de copiar.
- Usa Probar una ruta si tienes dudas sobre un archivo concreto.
Un consejo: añade siempre las plantillas de tu editor y tu sistema operativo, no solo la del lenguaje. La mitad del ruido de un repositorio compartido son .DS_Store de macOS y carpetas .idea de PhpStorm que nadie quería subir.
Las cinco cosas que conviene entender del formato
La última regla que coincide es la que manda
No la primera. Si tienes *.log y más abajo !importante.log, ese archivo concreto sí se sigue, porque la regla de negación aparece después. Invierte el orden y deja de funcionar. Es la fuente de casi todos los «no entiendo por qué se ignora esto».
La barra final restringe a directorios
build/ ignora la carpeta build, pero no un archivo llamado build. Sin la barra, build afecta a ambos. Cuando dudes, pon la barra: es más preciso y evita sorpresas.
La barra inicial ancla a la raíz
/dist ignora solo el dist de la raíz del repositorio. dist a secas ignora cualquier carpeta con ese nombre, a la profundidad que sea. En un monorepo la diferencia es enorme.
* se para en la barra, ** no
docs/*.md afecta a los .md que cuelgan directamente de docs. docs/**/*.md afecta también a los de sus subcarpetas.
.gitignore no borra lo que ya está versionado
Esta es la que más tiempo hace perder. Un .gitignore solo afecta a archivos que Git todavía no sigue. Si ya hiciste commit de algo, añadirlo al archivo no hace nada: hay que sacarlo del índice.
git rm --cached ruta/al/archivo
git commit -m "deja de versionar el archivo"
Para una carpeta entera, git rm -r --cached ruta/.
Si se te coló un .env
Merece su propio apartado porque es el accidente más caro y el peor entendido.
Sacar el archivo del índice no lo borra del historial. Cualquiera con acceso al repositorio puede recuperar el contenido de un commit anterior, y si el repositorio es público hay que asumir que ya fue indexado por algún rastreador. El único remedio real es:
- Rotar los secretos. Cambia las contraseñas, revoca las claves de API, regenera los tokens. Esto primero, antes que nada.
- Sacar el archivo del índice y añadirlo al
.gitignore. - Si de verdad hace falta limpiar el historial,
git filter-reporeescribe los commits, pero obliga a que todo el equipo vuelva a clonar.
El orden importa: reescribir el historial sin rotar las claves es hacer el trabajo difícil y dejar el peligro intacto.
Qué no hace esta herramienta
- No lee tu proyecto. Tú eliges las plantillas; no hay detección automática porque tendría que subir tus archivos a algún sitio.
- No explica todas las reglas. El diccionario cubre las más frecuentes del corpus. Las que no conocemos se muestran sin anotación, en lugar de inventar una explicación.
- No modifica tu repositorio. Genera texto que copias tú.
Sobre la fuente
Las plantillas vienen de github/gitignore, la colección oficial que mantiene GitHub, publicada bajo CC0 1.0, que es una renuncia a los derechos de autor: se puede usar y redistribuir sin obligaciones. Se cita igualmente porque es lo honesto.
Preguntas frecuentes
¿De dónde salen las plantillas?
Del repositorio github/gitignore, que es la colección oficial que mantiene GitHub y está publicada bajo CC0, o sea dominio público. Son 312 plantillas repartidas en lenguajes y frameworks, editores y sistemas operativos, y aportaciones de la comunidad. Se vendorizan enteras en la herramienta, así que funciona sin conexión a ningún servicio externo.
¿Incluye plantillas de stacks recientes como Bun o Tauri?
Sí, y es la diferencia principal con las herramientas veteranas del sector. El catálogo incluye Bun, Tauri, Expo, NestJS, Nix, OpenTofu, LangChain, Gleam y las de los editores de la generación actual como Cursor, Zed y los archivos de agentes. Muchos generadores populares llevan sin sincronizar sus plantillas desde 2023 y esas simplemente no están.
¿Qué significa la barra al final de una regla?
Limita la regla a directorios. Escribir build/ ignora la carpeta build pero no un archivo que se llame build sin extensión. Sin la barra, la regla afecta a los dos. La herramienta anota esto y el resto de detalles de sintaxis en cada regla que genera, que es justo lo que no te cuenta un bloque de texto pelado.
Ya hice commit de un archivo, ¿añadirlo al .gitignore lo borra?
No. El .gitignore solo afecta a archivos que Git todavía no sigue. Si ya lo commiteaste, tienes que sacarlo del índice con git rm --cached ruta/al/archivo y hacer commit de ese cambio. Y si lo que se te coló fue un .env con credenciales, sigue estando en el historial: hay que rotar esos secretos, porque borrarlos del archivo no los quita de los commits anteriores.
¿Para qué sirve el probador de rutas?
Para responder la pregunta que de verdad tienes: si un archivo concreto va a quedar ignorado o no. Escribes la ruta y te dice el resultado y, sobre todo, qué regla lo decidió. Es útil cuando combinas varias plantillas y alguna regla de negación con ! está reincluyendo algo sin que te des cuenta, porque en gitignore manda siempre la última regla que coincide.
Reseñas y valoraciones
Aún no hay reseñas. ¡Sé la primera persona en opinar!
Guías relacionadas
Tutoriales del blog donde esta herramienta resulta útil.
Herramientas relacionadas
Otras del catálogo que se usan bien junto a esta.