📦 Generador .gitignore / .dockerignore
Combina presets de lenguajes (Node, Python, Go, Rust, Java, PHP, Ruby), frameworks (React, Next.js, Django, Rails, Laravel), IDEs (VSCode, JetBrains, Vim) y SO (macOS, Windows, Linux) para generar .gitignore o .dockerignore en un clic. Sin duplicados, vista previa en vivo, copiar y descargar.
📝 .gitignore (vista previa)
# Selecciona al menos un preset
📖 Dónde se suele tropezar
Superpone preajustes de lenguaje, framework, IDE y sistema operativo para generar un .gitignore o un .dockerignore, eliminando lineas duplicadas y conservando los comentarios. Todo se ejecuta en el navegador. Ahora bien, un .gitignore solo afecta a los archivos que aun no se han anadido: un archivo que Git ya sigue no queda ignorado escribas lo que escribas. Y aqui vive el malentendido mas frecuente: confirmar un .env y anadirlo despues al .gitignore no lo quita ni del repositorio ni del historial. Ignorar algo y hacer que nunca haya ocurrido son cosas distintas.
| Caso | Qué ocurre | Qué hacer |
|---|---|---|
| No tiene efecto sobre archivos ya seguidos | Git deja de consultar el .gitignore para un archivo en cuanto pasa a estar seguido. De modo que un .env, un node_modules o un artefacto de compilacion que se confirmo una vez seguira apareciendo en los diffs por muchas reglas que anadas despues. Y el problema de verdad no es tu directorio de trabajo, sino el historial: dejar de seguirlo con git rm --cached no borra lo que contienen los commits pasados. Cualquiera puede leerlo con git log -p y, si ya lo has subido, el mismo contenido vive tambien en bifurcaciones, espejos, caches de CI y en cada clon. En un repositorio publico, los escaneres que recolectan claves de forma automatica lo encuentran en minutos: el tiempo observado entre publicar una clave y verla explotada se mide en minutos. |
Primero, deja de seguirlo: ejecuta git rm --cached .env y confirmalo junto con la adicion al .gitignore (si omites --cached, se borra el archivo en si). Anade -r para un directorio. Y si habia un secreto de por medio, hay exactamente un remedio: rota esa clave. Reescribir el historial con git filter-repo es posible, pero no lo conviertas en tu unica medida: todo el mundo tiene que volver a clonar, y no alcanza a las bifurcaciones ajenas ni a los objetos que ya subiste. Prevenir es con diferencia lo mas barato: acostumbrate a leer git status antes de git add y mete gitleaks o git-secrets en un hook de pre-commit. |
Copiar el .gitignore tal cual como .dockerignore |
Los dos comparten formato pero no proposito. Un .gitignore enumera lo que hay que dejar fuera del control de versiones; un .dockerignore enumera lo que no hay que enviar en el contexto de compilacion. Reutiliza uno como el otro y se rompe en ambos sentidos. Excluyes algo que la compilacion necesita: dist/ es una exclusion correcta para .gitignore, pero es un directorio imprescindible para un Dockerfile que hace COPY de un artefacto precompilado. Y a la inversa, conservas algo que deberia haberse excluido: sin excluir .git/ y node_modules/, el contexto alcanza cientos de megabytes y la compilacion se vuelve visiblemente mas lenta. Peor aun: un node_modules instalado en el anfitrion acaba en la imagen, mezclando modulos nativos compilados para otra plataforma que fallan en ejecucion. |
Escribe los dos por separado. Construye el .dockerignore desde la idea de dejar pasar solo lo que la compilacion de la imagen necesita y no te equivocaras: como minimo, descarta .git, node_modules, .env, *.log, pruebas, documentacion y configuracion de CI. Incluye siempre .env: si llega al contexto, COPY . . lo hornea dentro de la imagen y todo aquel a quien distribuyas esa imagen podra leerlo. Comprobar el efecto es facil: mira el tamano de contexto transferido que se imprime al inicio de docker build; unos pocos megabytes o menos es lo correcto. Y un .dockerignore solo se lee en la raiz del contexto de compilacion: uno colocado en un subdirectorio se ignora. |
| Un patron no casa donde creias | Pequenos detalles de sintaxis cambian el significado. Un patron sin barra, como build, casa con cualquier build a cualquier profundidad. Una barra inicial, /build, casa solo en la raiz, y una barra final, build/, casa solo con directorios. Lo mas dificil de ver es la negacion con !: si un directorio padre esta excluido, no puedes recuperar un archivo de su interior con !, porque Git no desciende a un directorio excluido y la regla que escribiste ni siquiera se lee. Pon node_modules/ y !node_modules/mylib uno junto al otro y el segundo no hace absolutamente nada. No aparece ningun error ni aviso, asi que solo se manifiesta como "lo escribi y no funciona". |
Ante la duda, ejecuta git check-ignore -v <ruta>. Imprime en una linea que regla, de que linea de que archivo, ha surtido efecto: conocer este comando cambia el tiempo de investigacion en un orden de magnitud. Si no imprime nada, esa ruta no esta siendo ignorada. Para recuperar un solo elemento dentro de un directorio, excluye el contenido en lugar del directorio: escribe node_modules/* y despues !node_modules/mylib y funcionara como pretendias. Apilar preajustes alarga el archivo, pero la longitud en si no es el problema: el problema es una linea que nadie sabe explicar, asi que agrupa al final, con un comentario, las lineas propias del proyecto. |
Los ajustes de exclusion no viven en un solo sitio. Git consulta, por orden, el .gitignore del repositorio, cualquier .gitignore de subdirectorios, .git/info/exclude y tu configuracion global (core.excludesFile). Hay un criterio claro para repartirlos: lo que sobra para todo el mundo en el proyecto (artefactos de compilacion, directorios de dependencias) va en el .gitignore del repositorio, mientras que lo propio de tu entorno (ajustes del editor, archivos que crea tu sistema operativo, notas personales) va en tu configuracion global. Poner .DS_Store, Thumbs.db o .idea/ en el .gitignore del repositorio es, en rigor, imponer tu entorno a los demas, aunque en la practica lo hace todo el mundo y acordarlo en equipo genera menos friccion. Por ultimo, Git no sigue directorios vacios: si necesitas que exista un logs/ vacio, coloca un archivo vacio en logs/.gitkeep (.gitkeep no es una funcion de Git, sino un nombre de archivo por convencion).
📖 Cómo usar
-
1
Elige un modoElige .gitignore o .dockerignore. .dockerignore prioriza patrones anti-bloat.
-
2
Elige stacksHaz clic en los chips de tu stack; se fusionan y deduplican.
-
3
Copia o descargaCopia o descarga como .gitignore / .dockerignore.
❓ Preguntas frecuentes
Diferencia entre .gitignore y .dockerignore?
Se puede agregar a un archivo existente?
Diferencia con github/gitignore?
Pueden agregar mas presets?
🔗 Herramientas relacionadas
🐛 ¿Encontró un problema con esta herramienta?
Gratis, sin registro. Incluso solo los pasos para reproducir ayudan. Los informes van directamente al operador y se usan para corregir.
¡Gracias por tu reporte!
Tu reporte llegó al operador y se usará para mejorar.