Cargando aplicación...
Preparando tu experiencia meskeIA
Crea archivos .gitignore profesionales combinando plantillas para tus tecnologías. Compatible con Node.js, Python, Java, React y más de 10 tecnologías.
3 tecnologías seleccionadas
# .gitignore generado con meskeIA
# https://meskeia.com/generador-gitignore
# Node.js
node_modules/
npm-debug.log*
yarn-debug.log*
yarn-error.log*
pnpm-debug.log*
lerna-debug.log*
.npm
.yarn-integrity
.env
.env.local
.env.development.local
.env.test.local
.env.production.local
dist/
build/
.next/
.nuxt/
.cache/
.vercel
.serverless/
# VS Code
.vscode/*
!.vscode/settings.json
!.vscode/tasks.json
!.vscode/launch.json
!.vscode/extensions.json
*.code-workspace
.history/
# macOS
.DS_Store
.AppleDouble
.LSOverride
Icon
._*
.DocumentRevisions-V100
.fseventsd
.Spotlight-V100
.TemporaryItems
.Trashes
.VolumeIcon.icns
.com.apple.timemachine.donotpresent
# General
*.log
*.tmp
*.temp
.env
.env.localEsta herramienta tiene carácter orientativo y está dirigida a profesionales del dominio que conocen sus limitaciones.
meskeIA no se responsabiliza de decisiones basadas en el uso de esta herramienta.
Descubre por qué es esencial, cuándo usarlo, errores comunes y mejores prácticas profesionales
El archivo .gitignore le indica a Git qué archivos y directorios NO debe rastrear en tu repositorio. Es fundamental para mantener tu repositorio limpio, seguro y eficiente.
Evita subir credenciales, API keys, tokens y archivos .env con información sensible. Un error puede exponer datos críticos públicamente.
Excluye dependencias (node_modules/, vendor/), builds (dist/, target/) y archivos temporales. Reduce el tamaño del repo un 90%.
Filtra archivos del sistema (.DS_Store, Thumbs.db), logs y cachés que no aportan valor al código fuente.
Evita conflictos de merge por archivos de configuración personal de IDEs (.vscode/, .idea/). Cada desarrollador tiene su entorno sin contaminar el repo.
Compara las ventajas y desventajas de diferentes métodos para crear tu .gitignore
| Método | Velocidad | Precisión | Personalización | Mejor para | Inconveniente |
|---|---|---|---|---|---|
| Manual | ⏱️ Lento | ⭐⭐⭐⭐⭐ Alta | 🎯 Máxima | Proyectos únicos, expertos Git | Propenso a olvidos, laborioso |
| Templates GitHub | ⚡ Rápido | ⭐⭐⭐⭐ Buena | 📝 Media | Proyectos estándar mono-tecnología | Limitado a una tecnología a la vez |
| gitignore.io | ⚡ Rápido | ⭐⭐⭐⭐ Buena | 🔧 Media-Alta | Proyectos multi-tecnología estándar | Requiere conexión, interfaz externa |
| meskeIA Generator | ⚡ Rápido | ⭐⭐⭐⭐ Buena | 🎯 Alta | Proyectos multi-stack, principiantes | Plantillas predefinidas (pero editables) |
| IDE plugins | ⚡⚡ Muy rápido | ⭐⭐⭐ Media | 📝 Baja | Workflows integrados en IDE | Depende del IDE, menos control |
| Sin .gitignore | ⚡⚡⚡ Instantáneo | ❌ Nula | - | Nunca (riesgo de seguridad) | Expone secretos, repo gigante, conflictos |
Escenarios reales donde un .gitignore bien configurado marca la diferencia
Configuración:
✅ Node.js + React + VS Code + macOS
✅ Resultado: 40+ patrones combinados
⚠️ Evita: node_modules/ (300 MB), .next/ (build), .env (API keys)Por qué funciona: Clonar el repo sin .gitignore tardaría 5 minutos vs 10 segundos con él. Protege tus secrets desde el primer commit.
Configuración:
✅ Python + JetBrains (PyCharm) + Windows
✅ Resultado: Ignora __pycache__/, venv/, .ipynb_checkpoints/
⚠️ Evita: Archivos de entorno (200 MB+), checkpoints innecesariosPor qué funciona: Los entornos virtuales (venv/) pueden pesar 500 MB+. Cada colaborador crea el suyo sin saturar el repo.
Configuración:
✅ Java + JetBrains (IntelliJ) + macOS
✅ Resultado: Excluye target/, .idea/, *.class
⚠️ Evita: Archivos compilados (gigabytes), configs IDE personalesPor qué funciona: Los .class compilados cambian en cada build. Con .gitignore solo subes código fuente, no binarios.
Configuración:
✅ Node.js + .env (API keys, DB passwords)
✅ Resultado: .env en .gitignore ANTES del primer commit
🚨 Crítico: Una vez en Git, eliminar .env es complejo (reescribir historial)Por qué funciona: Previene exposición pública de credenciales. Usa .env.example con placeholders para documentar variables necesarias.
Configuración:
✅ React (algunos usan VS Code, otros JetBrains, otros Sublime)
✅ Resultado: Ignora .vscode/, .idea/, *.sublime-*
⚠️ Evita: Conflictos de merge por configuraciones personalesPor qué funciona: Cada desarrollador tiene sus extensiones/configuraciones sin afectar a otros. El código es lo que importa, no el IDE.
Configuración:
✅ Node.js + Python + Go + Rust (microservicios)
✅ Resultado: .gitignore raíz combina todos los patrones
⚠️ Evita: node_modules/, venv/, target/, duplicar 4× las dependenciasPor qué funciona: Un .gitignore completo en la raíz cubre todos los subdirectorios. Puedes añadir .gitignore específicos por carpeta si necesitas excepciones.
Sí. Git soporta .gitignore en cualquier directorio. Las reglas se combinan:
• .gitignore raíz: Reglas globales del proyecto
• frontend/.gitignore: Reglas específicas de frontend
• backend/.gitignore: Reglas específicas de backend
Tip: Usa .gitignore raíz para patrones comunes (node_modules/, .env) y específicos para excepciones locales.
Si ya hiciste commit de archivos como .env o node_modules/, añadirlos a .gitignore NO los elimina del historial. Debes:
1. Eliminar del índice (sin borrar local):git rm --cached .env (un archivo)git rm -r --cached node_modules/ (carpeta)
2. Confirmar el cambio:git commit -m "Remove sensitive files from tracking"
⚠️ Importante: Si subiste secrets públicamente, rótalos inmediatamente. El historial de Git conserva los commits antiguos. Para reescribir historial: git filter-branch o BFG Repo-Cleaner (avanzado).
Ejecuta git status después de crear .gitignore. Los archivos ignorados no deben aparecer en "Untracked files".
Comandos útiles:
• git status --ignored: Muestra archivos ignorados
• git check-ignore -v archivo.log: Explica por qué se ignora un archivo
• git add -f archivo.log: Fuerza añadir un archivo ignorado (usar con precaución)
Depende del tipo de configuración:
✅ SÍ ignorar (personal):
• .vscode/settings.json (preferencias individuales)
• .idea/workspace.xml (estado de ventanas del IDE)
• .editorconfig NO (este SÍ debe compartirse)
❌ NO ignorar (equipo):
• .prettierrc (formato de código compartido)
• eslint.config.js (linting del equipo)
• .nvmrc / .tool-versions (versiones de Node/herramientas)
Regla de oro: Si el archivo garantiza consistencia en el equipo, NO lo ignores. Si es preferencia personal, SÍ.
Usa el patrón ! (negación) después de ignorar todo:
Ejemplo: Ignorar todo en /builds/ excepto production.jsbuilds/*
!builds/production.js
Ejemplo: Ignorar todos los .log excepto important.log*.log
!important.log
⚠️ Importante: La negación NO funciona si ya ignoraste el directorio padre. Ejemplo: build/ ignora TODO dentro, !build/file.txt NO funcionará. Solución: build/* en lugar de build/.
Git soporta tres niveles de reglas de ignorar:
1. .gitignore (proyecto)
• Ubicación: Raíz del repo (o subdirectorios)
• Alcance: Compartido con todo el equipo (vía Git)
• Uso: Patrones comunes del proyecto (node_modules/, dist/)
2. .git/info/exclude (local)
• Ubicación: Dentro de .git/ (NO se sube al repo)
• Alcance: Solo tu máquina local
• Uso: Archivos personales temporales (notas.txt, TODO.md)
3. ~/.gitignore_global (global del sistema)
• Ubicación: Tu carpeta de usuario
• Alcance: TODOS tus repos Git
• Uso: Patrones de SO/IDE (.DS_Store, Thumbs.db, .idea/)
• Config: git config --global core.excludesfile ~/.gitignore_global
Recomendación: Usa .gitignore (proyecto) para patrones del equipo, .gitignore_global para patrones de tu máquina, .git/info/exclude para casos excepcionales locales.
Depende del sistema de archivos:
• Linux/Unix: Sí (case-sensitive). README.md ≠ readme.md
• macOS/Windows: No (case-insensitive). README.md = readme.md
Mejor práctica: Usa siempre minúsculas en patrones para evitar problemas cross-platform:
*.log # ✅ Funciona en todos los sistemas
*.LOG # ⚠️ Solo funciona en Linux si el archivo es .LOG
Depende del tipo de proyecto:
✅ NO IGNORAR (aplicaciones):
• package-lock.json / yarn.lock (Node.js apps)
• Cargo.lock (Rust apps)
• Gemfile.lock (Ruby apps)
Razón: Garantiza que todos los desarrolladores/producción usen las mismas versiones exactas de dependencias. Evita bugs tipo "en mi máquina funciona".
❌ SÍ IGNORAR (librerías/paquetes):
• Si estás creando una librería NPM/Rust crate/Ruby gem que otros instalarán
Razón: Los consumidores de tu librería deben resolver sus propias dependencias. Los lock files pueden causar conflictos.
Regla de oro: ¿Despliegas la app? → NO ignores. ¿Publicas como paquete? → SÍ ignora.
Usa este generador para crear el archivo con las tecnologías de tu proyecto. Descárgalo y guárdalo como .gitignore (con punto al inicio) en la raíz del repositorio.
⚠️ Crítico: Si ya hiciste git init pero AÚN NO hiciste git add ., estás a tiempo. Si ya hiciste commit de node_modules/ o .env, tendrás que limpiar el historial.
Ejecuta git status. Los archivos/carpetas en .gitignore NO deben aparecer en "Untracked files". Si aparecen:
• Revisa que el patrón en .gitignore es correcto (ej: node_modules/ con barra al final para carpetas)
• Usa git check-ignore -v node_modules/ para debugging
• Si ya están rastreados, usa git rm --cached -r node_modules/
El archivo .gitignore SÍ debe estar en el repo para que todo el equipo lo use:
git add .gitignore
git commit -m "Add .gitignore for Node.js, React, VS Code"
Tip: Haz este commit ANTES de añadir el código. Así proteges secrets desde el inicio.
Crea un .gitignore global para patrones de tu OS/IDE que NO son específicos del proyecto:
# Crear archivo
touch ~/.gitignore_global
# Añadir patrones (macOS, VS Code)
echo ".DS_Store" >> ~/.gitignore_global
echo ".vscode/" >> ~/.gitignore_global
# Configurar Git para usarlo
git config --global core.excludesfile ~/.gitignore_global
Ventaja: Evitas añadir .DS_Store a cada proyecto individual.
Si tu proyecto usa variables de entorno (.env), crea un .env.example con placeholders:
# .env (IGNORADO, NO subir)
DATABASE_URL=postgresql://user:password@localhost:5432/mydb
API_KEY=sk-ant-api03-1234567890
# .env.example (SÍ subir al repo)
DATABASE_URL=postgresql://user:password@localhost:5432/dbname
API_KEY=your_api_key_here
Propósito: Los nuevos desarrolladores saben qué variables necesitan sin exponer valores reales.
Si incorporas nuevas herramientas al proyecto (ej: añades Docker, Terraform), actualiza .gitignore:
• Docker: .docker/, *.log
• Terraform: .terraform/, *.tfstate, *.tfvars
• Cache de frameworks: .next/, .nuxt/, .cache/
Tip: Usa este generador para regenerar el .gitignore con las nuevas tecnologías.
Ejecuta git status --ignored cada cierto tiempo para verificar que no ignoras archivos importantes por error.
Señales de alerta:
• Si src/ o lib/ aparecen ignorados → Revisa patrones demasiado amplios
• Si archivos de config del equipo se ignoran → Revisa que no confundiste configs personales vs compartidas
Tip: Usa patrones específicos (*.log) en lugar de amplios (*).
Añade .env, *.pem, *.key a .gitignore ANTES del primer commit. Rotar credenciales expuestas es costoso.
Usa *.log en lugar de *. Patrones amplios pueden ignorar código fuente accidentalmente.
Si usas patrones avanzados (**/*.test.{ js,ts}), añade un comentario explicando su propósito para el equipo.
Usa el mismo .gitignore en todos los entornos (dev, staging, prod). Evita "funciona en mi máquina" por archivos diferentes.
Ejecuta git status antes de git push. Asegúrate de que no subes node_modules/ o .env por error.
Ignora dist/, build/, target/ (generados). NUNCA ignores src/ o lib/ (código fuente).
git rm --cached .env y rota las credenciales inmediatamente.*.js ignoraría TODO el JavaScript, incluyendo tu código fuente. Sé específico: dist/*.js..vscode/settings.json (personal) debe ignorarse. .prettierrc (equipo) NO.git add archivo.log, añadirlo a .gitignore después NO lo ignora. Usa git rm --cached archivo.log primero.node_modules ignora archivos Y carpetas. node_modules/ solo ignora la carpeta. Usa barra para claridad.