Cómo generar un .gitignore correcto para tu proyecto

Haces git add . sin pensarlo y de repente tu repositorio tiene 200.000 archivos de node_modules, tu carpeta .vscode personal, y en el peor de los casos, un .env con claves de API reales. Todo esto se evita con un archivo .gitignore bien configurado desde el primer commit, no después de que el daño ya esté hecho.

Qué hace un .gitignore

Un archivo .gitignore le dice a Git qué archivos y carpetas no debe rastrear ni incluir en el control de versiones. Es una lista de patrones (nombres de archivo, extensiones, carpetas) que Git ignora automáticamente al hacer git add o git status.

Por qué necesitas uno distinto por proyecto

Cada lenguaje y framework genera su propio tipo de archivos temporales o generados que no deberían versionarse:

• Node.js: node_modules/, con miles de archivos que se reinstalan con npm install, no que se versionan.
• Python: __pycache__/, entornos virtuales (venv/), archivos .pyc.
• Editores: carpetas de configuración propias de VS Code (.vscode/), IntelliJ (.idea/), que son preferencias personales, no parte del proyecto.
• Sistemas operativos: .DS_Store en macOS, Thumbs.db en Windows, archivos que el sistema operativo genera automáticamente y no aportan nada al proyecto.
• Variables de entorno: .env, donde suelen vivir claves de API, contraseñas de base de datos y secretos que nunca deben acabar en un repositorio público.

Un .gitignore genérico copiado de otro proyecto sin adaptar rara vez cubre exactamente lo que tu stack concreto necesita.

Cómo generar tu .gitignore

1. Selecciona los lenguajes y frameworks que usa tu proyecto (Node, Python, React, etc.).
2. Añade tu editor si quieres incluir también sus carpetas de configuración.
3. La herramienta combina todas las plantillas seleccionadas en un solo archivo.
4. Copia o descarga el resultado como .gitignore en la raíz de tu proyecto.

Puedes hacerlo gratis con el generador de .gitignore de esta web.

El error que de verdad importa: archivos ya subidos

Añadir .gitignore no elimina archivos que ya se subieron antes en commits anteriores; solo evita que se rastreen nuevos cambios en ellos a partir de ahora. Si ya subiste un .env con secretos reales por error, añadir la regla al .gitignore no lo borra del historial de Git, y esas claves siguen siendo recuperables por cualquiera con acceso al repositorio. En ese caso, además de añadir la regla, hay que rotar las credenciales expuestas y, si es necesario, reescribir el historial para eliminarlas.

Cuándo añadir el .gitignore

Idealmente, antes del primer commit. Si el proyecto ya tiene historial, añadirlo cuanto antes evita que el problema crezca, aunque no retroactivamente para lo ya subido.

Preguntas frecuentes

¿Puedo combinar varios lenguajes en un mismo .gitignore? Sí, es habitual en proyectos full-stack (por ejemplo, Node en el backend y React en el frontend); la herramienta combina las plantillas necesarias en un único archivo.

¿El .gitignore afecta a archivos que ya están versionados? No, solo a archivos nuevos o no rastreados todavía; para dejar de rastrear uno que ya está en el repositorio hay que quitarlo explícitamente con git rm --cached.

¿Debo subir el .gitignore al repositorio? Sí, es parte del proyecto y debe compartirse con todo el equipo para que las mismas reglas apliquen a todos.

¿Qué hago si subí un .env por error? Añade la regla al .gitignore, elimina el archivo del repositorio con git rm --cached .env, y rota inmediatamente cualquier clave o contraseña que contuviera.

Genera el .gitignore correcto para tu proyecto gratis con el generador de .gitignore, combinando lenguajes, frameworks y editores al instante.