EN
PT
ES
Generador de Gitignore
Elige tu stack, sistema operativo y editor y obtén un .gitignore limpio y sin duplicados de un clic.
¿Qué es un archivo .gitignore?
Un archivo .gitignore le dice a Git qué rutas debe dejar fuera del control de versiones. Vive en la raíz de tu repositorio y se versiona con él — así cada clon aplica las mismas reglas. Sin uno, terminas versionando binarios compilados, carpetas de dependencias, cachés del IDE, archivos de log y (lo peor) secretos como archivos .env. Cuando eso entra al historial, queda buscable para siempre, incluso después de un force-push, y por eso afinar el .gitignore al inicio del proyecto importa más de lo que parece. Este generador combina patrones probados en producción para los lenguajes, frameworks, sistemas operativos y editores que de verdad usas, y mantiene los encabezados sin duplicados para que el archivo siga siendo legible. Solo emite patrones de ruta — nunca código fuente — así que es seguro pegarlo directo en un repositorio público. Si tu proyecto mezcla un backend, un frontend, dos sistemas operativos y tres editores en el equipo, marca todos: el resultado es un único archivo, no una carpeta, y Git trata cada línea como aditiva. Úsalo como punto de partida y ajusta desde ahí.
Cómo usarlo
1. Elige tus plantillas
Haz clic en cualquier chip de las listas de lenguaje, sistema operativo o editor. Usa el filtro de arriba si la lista crece — coincide con la etiqueta y con la clave interna.
2. Revisa la salida
Cada plantilla tiene su propio encabezado comentado (# === Node.js ===) para identificar de un vistazo de dónde viene cada regla. El orden es el orden en que hiciste clic.
3. Copia o descarga
Copia todo al portapapeles, o pulsa Descargar para guardarlo directamente como .gitignore. Ponlo en la raíz del repositorio antes del primer commit.
4. Ajusta lo necesario
Trata la salida como punto de partida. Agrega rutas específicas del proyecto (uploads, docs generados, archivos de borrador) al final, y elimina cualquier regla que no aplique a tu setup.
Qué hace cada regla
Los patrones de .gitignore siguen reglas simples. Una ruta literal como node_modules/ ignora ese directorio donde sea que aparezca. Una barra inicial (/dist) ancla el patrón a la raíz del repositorio. Los caracteres glob funcionan como esperas: *.log coincide por extensión, **/cache recurre, y los corchetes como *.[oa] coinciden con un conjunto. Un ! inicial niega una regla previa — así Unity conserva los archivos .meta aunque su objetivo esté ignorado. Las líneas que empiezan con # son comentarios. La barra final significa “solo directorio”. Los archivos ya rastreados no se ven afectados — para dejar de versionar uno tras agregarlo al .gitignore, ejecuta git rm --cached ruta.
Cuándo agregar qué
Usa plantillas de lenguaje y framework para artefactos de build y carpetas de dependencias (node_modules/, vendor/, target/). Agrega la plantilla de SO según los sistemas que use el equipo — macOS deja .DS_Store por todos lados y Windows desperdiga Thumbs.db. Agrega una plantilla de editor según el IDE estándar del equipo; si hay mezcla, agrégalas todas. Regla práctica: al menos un stack + un SO + un editor para cualquier repo nuevo. Evita ignorar lockfiles (package-lock.json, composer.lock, Gemfile.lock) — deben versionarse para builds reproducibles.
Preguntas frecuentes
¿Esto va a versionar algo de mi código?
.gitignore.¿Dónde pongo el archivo?
.gitignore (con el punto inicial). Puedes tener .gitignores adicionales en subcarpetas — Git aplica el más cercano a cada ruta.Ya commité archivos que debería haber ignorado. ¿Y ahora?
.gitignore y ejecuta git rm --cached ruta para dejar de rastrear el archivo (sigue en disco). Comitea eso y, de ahí en más, Git lo deja en paz. Para secretos que ya entraron al historial, rótalos y reescribe el historial con git filter-repo.¿Debo commitear el propio .gitignore?
.gitignore son reglas compartidas — cada colaborador necesita el mismo archivo. Comitéalo como cualquier otro archivo del proyecto.¿Y los lockfiles?
package-lock.json, yarn.lock, composer.lock, Gemfile.lock, poetry.lock) se deben versionar, no ignorar. Fijan versiones exactas para que todos obtengan el mismo build. Las plantillas aquí no ignoran lockfiles por defecto — Rails es la excepción histórica en algunos setups, y mantenemos la convención upstream.¿También necesito un gitignore global?
.gitignore global (configurado con git config --global core.excludesFile) es el lugar correcto para el ruido personal de editor y SO, así no lo repites en cada repo. Las reglas a nivel proyecto deben seguir cubriendo lenguaje, framework y la configuración de editor acordada con el equipo.