Gestión de archivos ignorados en Git: .gitignore por lenguaje y repositorios limpios

¿Para qué sirve .gitignore?

.gitignore es un archivo de configuración que le dice a Git qué rutas o patrones de archivos debe no incluir cuando detecta cambios para preparar un commit. Su objetivo es mantener el repositorio limpio y enfocado en el código fuente y archivos necesarios para construir/ejecutar el proyecto, evitando artefactos generados automáticamente (builds, cachés, dependencias descargadas, logs, archivos de IDE, etc.).

Puntos clave:

• Ignorar afecta principalmente a archivos no trackeados (nuevos para Git).
• Si un archivo ya está versionado (trackeado), agregarlo a .gitignore no lo deja de trackear automáticamente.
• Se pueden tener múltiples .gitignore: uno en la raíz (común) y otros en subcarpetas (más específicos).

Ignorar archivos nuevos vs dejar de trackear archivos ya versionados

1) Ignorar archivos nuevos (no trackeados)

Si un archivo todavía no está en Git, basta con añadir el patrón a .gitignore. Ejemplo: ignorar logs.

# .gitignore
*.log

Verificación rápida:

git status

Si el archivo era no trackeado, dejará de aparecer como “untracked”.

Continúa en nuestra aplicación.

• Escuche el audio con la pantalla apagada.
• Obtenga un certificado al finalizar.
• ¡Más de 5000 cursos para que explores!

O continúa leyendo más abajo...

Descargar la aplicación

2) Dejar de trackear un archivo ya versionado

Si el archivo ya fue añadido y commiteado, Git lo seguirá considerando parte del historial. Para dejar de trackearlo (manteniéndolo en tu disco), debes:

• Agregar el patrón a .gitignore.
• Quitar el archivo del índice (staging) con --cached.

# 1) Añade el patrón al .gitignore (ejemplo: archivo de entorno)
# .gitignore
.env

# 2) Deja de trackearlo (pero no lo borres del disco)
git rm --cached .env

# 3) Confirma el cambio
git add .gitignore
git commit -m "Stop tracking .env and ignore it"

Importante: esto no borra el archivo del historial anterior. Si contenía secretos, considera rotarlos y usar herramientas de limpieza de historial (tema avanzado y delicado).

Cómo escribir patrones en .gitignore (reglas frecuentes)

Git interpreta patrones estilo “glob”. Reglas comunes:

• *.log: ignora cualquier archivo con extensión .log.
• build/: ignora una carpeta llamada build (en cualquier nivel si no se ancla).
• /build/: ignora build solo en la raíz del repo.
• **/dist/: ignora dist en cualquier subcarpeta (útil en monorepos).
• !keep.me: excepción (no ignorar) para un archivo que coincida con un patrón ignorado.
• #: comentario.

Ejemplos prácticos de patrones

# Logs
*.log

# Cachés
.cache/

# Builds
/dist/
/build/

# Archivos del sistema
.DS_Store
Thumbs.db

# IDEs
.vscode/
.idea/
*.iml

Cómo probar y depurar reglas de .gitignore

Ver qué está ignorado

git status --ignored

Esto muestra archivos ignorados (útil para confirmar que tus patrones funcionan).

Explicar por qué un archivo está ignorado (o no)

git check-ignore -v ruta/al/archivo

La opción -v indica qué regla y qué archivo .gitignore causó el ignore.

Simular qué archivos serían trackeados

Para ver qué archivos no ignorados existen (y podrían terminar en un commit):

git ls-files --others --exclude-standard

Esto lista archivos no trackeados respetando .gitignore y reglas estándar.

Plantillas por tipo de proyecto: qué ignorar y por qué

Las listas siguientes se enfocan en categorías típicas: dependencias, entornos, builds, cachés, logs y archivos de IDE. Ajusta según tu estructura real.

Node.js / JavaScript / TypeScript

Categorías recomendadas:

• Dependencias: se reinstalan desde package.json/package-lock.json/pnpm-lock.yaml.
• Builds: salida de bundlers/compiladores.
• Cachés: herramientas como npm, yarn, eslint, vite, next.
• Logs: logs de ejecución.
• Entorno: archivos .env con secretos.

# Dependencias
node_modules/

# Builds
/dist/
/build/
/.next/
/out/

# Cachés
.npm/
.yarn/cache/
.eslintcache
.vite/

# Logs
npm-debug.log*
yarn-debug.log*
yarn-error.log*
*.log

# Entorno
.env
.env.*
!.env.example

Python

Categorías recomendadas:

• Entornos virtuales: venv, .venv.
• Bytecode: __pycache__, .pyc.
• Builds/paquetes: dist, build, .egg-info.
• Herramientas: cachés de pytest, mypy, coverage.
• Entorno: .env.

# Entornos virtuales
.venv/
venv/

# Bytecode
__pycache__/
*.py[cod]

# Builds
build/
dist/
*.egg-info/

# Herramientas / cachés
.pytest_cache/
.mypy_cache/
.coverage
htmlcov/

# Entorno
.env
.env.*
!.env.example

Java (Maven/Gradle) y Kotlin (JVM)

Categorías recomendadas:

• Builds: target (Maven), build (Gradle).
• Cachés: Gradle.
• IDE: IntelliJ/Android Studio.
• Logs: si aplica.

# Maven
/target/

# Gradle
/build/
.gradle/

# IDE (IntelliJ)
.idea/
*.iml

# Logs
*.log

.NET (C# / F#)

Categorías recomendadas:

• Builds: bin, obj.
• IDE: Visual Studio, Rider.
• Paquetes: cachés locales si se generan dentro del repo.
• Logs: si aplica.

# Builds
**/bin/
**/obj/

# IDE
.vs/
.idea/
*.user
*.suo

# Logs
*.log

C / C++ (Make/CMake)

Categorías recomendadas:

• Builds: carpetas de compilación fuera del código fuente.
• Artefactos: binarios, objetos, librerías.
• Cachés: CMake.
• IDE: VS Code/CLion.

# Builds
/build/
/cmake-build-*/

# Artefactos
*.o
*.obj
*.a
*.lib
*.so
*.dll
*.dylib
*.exe

# CMake
CMakeCache.txt
CMakeFiles/

# IDE
.vscode/
.idea/

Móviles: Android (Gradle) y iOS (Xcode)

Android (Java/Kotlin)

• Builds: salidas de Gradle.
• Cachés: Gradle.
• IDE: Android Studio.
• Archivos locales: configuraciones por máquina.

# Gradle/Android
**/build/
.gradle/

# Android Studio / IntelliJ
.idea/
*.iml

# Archivos locales
local.properties

iOS (Swift/Objective-C)

• Builds: DerivedData.
• Dependencias: según gestor (CocoaPods, SPM, Carthage) y política del equipo.
• IDE: Xcode.

# Xcode
DerivedData/
*.xcuserstate
*.xcuserdata/

# CocoaPods (si tu equipo decide no versionar Pods)
Pods/

# Carthage
Carthage/Build/

Repositorios limpios: recomendaciones prácticas

1) Ignora artefactos, no fuentes

Regla mental: si se puede regenerar con un comando (instalar dependencias, compilar, ejecutar tests), normalmente se ignora. Ejemplos: node_modules/, dist/, build/, __pycache__/, bin/, obj/.

2) Archivos sensibles: .env, claves y credenciales

No versionar secretos. En su lugar:

• Ignora .env y variantes.
• Versiona una plantilla: .env.example (o .env.template) con variables vacías o valores de ejemplo.
• Configura secretos con variables de entorno en tu sistema/CI.

# .gitignore
.env
.env.*
!.env.example

# .env.example
DATABASE_URL=
API_KEY=
DEBUG=false

3) Diferencia entre .gitignore del repo y exclusiones locales

Si hay archivos que solo tú quieres ignorar (por ejemplo, notas personales), evita ensuciar el .gitignore del equipo. Usa el archivo local:

.git/info/exclude

Funciona como un .gitignore privado para ese clon.

Ejercicio: limpiar un repositorio “contaminado” con artefactos

Objetivo: eliminar del tracking archivos generados (por ejemplo node_modules/, dist/, logs) que ya fueron commiteados por error, y dejar reglas correctas en .gitignore.

Escenario

Tu repositorio tiene:

• node_modules/ trackeado.
• dist/ trackeado.
• Varios *.log trackeados.
• Un .env

Paso 1: crear/actualizar .gitignore

# Dependencias
node_modules/

# Builds
/dist/

# Logs
*.log

# Entorno
.env
.env.*
!.env.example

# IDE
.vscode/
.idea/

Paso 2: verificar qué reglas aplican

git status --ignored
git check-ignore -v dist/app.js
git check-ignore -v .env

Paso 3: dejar de trackear lo que ya estaba versionado

Quita del índice (sin borrar del disco) las carpetas/archivos que ahora deben ser ignorados:

# Carpetas completas
git rm -r --cached node_modules dist

# Logs (si hay muchos, puedes repetir por carpeta o listar rutas)
git rm --cached *.log

# Archivo sensible
git rm --cached .env

Si algunos patrones no coinciden desde la raíz (por ejemplo logs en subcarpetas), usa rutas explícitas o repite el comando donde aplique:

git rm -r --cached path/a/logs/
git rm --cached path/a/logs/app.log

Paso 4: revisar el staging antes de confirmar

git status
git diff --staged

Paso 5: commitear la limpieza

git add .gitignore
git commit -m "Clean repo: ignore build artifacts, dependencies, logs and env files"

Paso 6: comprobar que ya no reaparecen

Genera de nuevo artefactos (ejecuta build o instala dependencias) y confirma:

git status

Deberías ver el repositorio limpio o, como mucho, cambios en archivos fuente reales. Si algo sigue apareciendo, depúralo con:

git check-ignore -v ruta/al/archivo

Tabla rápida: qué ignorar por categoría