Git tiene más formas de ignorar archivos

Si trabajas con Git todos los días, seguro ya usaste .gitignore para dejar fuera archivos que no deberían entrar al repositorio. El problema es que mucha gente cree que esa es la única forma de ignorar cosas, y no lo es. En equipos reales, con varios entornos locales, secretos distintos y archivos que cambian solo en tu máquina, conocer las alternativas te ahorra commits accidentales y discusiones innecesarias.

La diferencia entre “ignorar un archivo para todo el equipo” y “dejar de ver cambios locales en mi copia” parece pequeña, pero en la práctica cambia mucho. No se resuelve igual un node_modules, un archivo de variables de entorno, un archivo generado por tu editor o una configuración que solo tú necesitas modificar. Git tiene varias herramientas para cada caso, y si eliges mal, terminas con ruido en git status o, peor, con cambios que no querías subir.

La idea base: no todo se ignora igual

La forma más conocida es .gitignore, que sirve para decirle a Git qué archivos no debe seguir como nuevos ni mostrar como no rastreados. Eso funciona bien para cosas como dependencias, builds, logs y archivos locales que nadie debería versionar. Pero .gitignore solo aplica a archivos que Git todavía no está rastreando, o a patrones que quieres excluir desde el inicio.

Si un archivo ya está dentro del repositorio, ponerlo en .gitignore no lo saca mágicamente del seguimiento. Ese es uno de los errores más comunes en equipos nuevos y también en equipos con gente experimentada que cambia de proyecto rápido. Git sigue viendo ese archivo porque ya forma parte del historial y del árbol de trabajo rastreado.

Por eso conviene separar los casos en dos preguntas simples: ¿quieres que nadie lo versiona desde ahora? ¿O solo quieres que tu copia local deje de mostrar cambios? La respuesta define si usas .gitignore, un archivo de exclusión local, o flags como assume-unchanged y skip-worktree.

Cuándo .gitignore sí es la opción correcta

Usa .gitignore cuando el archivo o patrón no debería entrar al repositorio para nadie. Ejemplos típicos: node_modules/, dist/, coverage/, .env, *.log o archivos temporales de tu editor. Si el patrón es parte del proyecto y aplica igual para todo el equipo, este es el lugar correcto.

También sirve cuando estás iniciando un repo y quieres fijar reglas desde el comienzo. Por ejemplo, en un proyecto de Next.js suele tener sentido ignorar .next/, y en un backend con Node, ignorar logs/ y archivos de cache. Eso evita que cada dev tenga que recordar reglas manuales.

Un detalle útil: .gitignore se versiona, así que el equipo ve exactamente la misma política de exclusión. Si trabajas con gente en LatAm, donde no siempre todos usan la misma versión de editor, sistema operativo o shell, eso reduce bastante el ruido por archivos generados localmente.

.gitignore: lo que hace bien y lo que no

.gitignore no borra archivos del historial, solo evita que Git empiece a rastrearlos en el futuro o que te los muestre como no rastreados. Si el archivo ya está trackeado, primero tienes que sacarlo del índice con git rm --cached. Después sí, la regla de ignore hará su trabajo para futuras modificaciones no deseadas.

Un ejemplo típico:

git rm --cached .env
echo ".env" >> .gitignore
git add .gitignore
git commit -m "Ignore environment file"

Ese flujo es útil cuando alguien subió un archivo sensible por error. Ojo: git rm --cached quita el archivo del seguimiento, pero no lo borra de tu disco si usas --cached. Eso te permite conservarlo localmente mientras deja de existir en el repo.

Reglas globales para tu máquina

Además del .gitignore del proyecto, Git permite un archivo de exclusión global para tu usuario. Esto sirve para ignorar cosas que solo te afectan a ti, como archivos de tu editor, configuraciones del sistema o basura generada por herramientas que usas localmente pero que no quieres repetir en cada repo.

La documentación oficial de Git explica cómo configurar ese archivo global en core.excludesFile: https://git-scm.com/docs/gitignore

Un caso práctico: si usas macOS, puedes ignorar .DS_Store globalmente. Si usas Windows, quizá quieras excluir Thumbs.db. Eso evita meter esas reglas en cada proyecto si no tienen valor para el equipo completo.

Alternativas para archivos ya rastreados

Aquí está la parte que más confunde. Si el archivo ya está tracked y solo quieres que Git deje de marcarlo como modificado en tu copia local, hay dos opciones que suelen aparecer en conversaciones: assume-unchanged y skip-worktree. No son lo mismo, y no sirven para el mismo problema.

Ambas opciones son útiles, pero también peligrosas si las usas como si fueran una solución de equipo. Son más bien herramientas de trabajo local, no políticas del repo. Si las mezclas con cambios que otras personas sí esperan ver, puedes terminar con conflictos raros o con archivos desincronizados sin darte cuenta.

assume-unchanged: para cambios que tú no quieres vigilar

git update-index --assume-unchanged <archivo> le dice a Git que, en teoría, ese archivo no cambiará localmente y que no necesita revisarlo tan seguido. Es una optimización y una pista, no una regla fuerte. Git puede volver a mirar el archivo si lo necesita.

Ejemplo:

git update-index --assume-unchanged config/local.json

Esto puede servir si tienes un archivo rastreado que casi nunca cambia y tu flujo local lo modifica por herramientas externas, pero tú no quieres verlo en git status cada cinco minutos. Aun así, no es buena idea usarlo para secretos, configuraciones críticas o archivos que otros devs sí editan con frecuencia.

skip-worktree: para respetar tu copia local

git update-index --skip-worktree <archivo> es más fuerte para el caso de “no me toques mi versión local”. Git intenta dejar tu copia de trabajo en paz, lo que lo vuelve útil para archivos de configuración que el repo comparte, pero que tú ajustas por entorno.

Ejemplo:

git update-index --skip-worktree config/app.local.json

Esto puede ser práctico cuando el proyecto trae un archivo base y tú necesitas cambios locales para apuntar a otra base de datos, otro puerto o un servicio distinto. Pero tiene una trampa: si alguien cambia ese archivo en el repo, tú puedes no verlo de inmediato y luego sufrir al hacer merge o pull.

Diferencia práctica entre ambos

Git documenta estas opciones en su manual de index y ignore rules. Si quieres revisar el comportamiento exacto, la referencia oficial está en https://git-scm.com/docs/git-update-index

Cómo elegir sin meterte en problemas de equipo

La regla más útil es esta: si el archivo afecta a todo el equipo, la solución debe vivir en el repositorio. Si solo te afecta a ti, la solución debe vivir en tu máquina. Si el archivo ya está tracked y necesitas una excepción local, usa una herramienta local con cuidado, no una regla compartida.

En equipos con varios entornos, el conflicto típico aparece con archivos como config.json, settings.php, .env.local o archivos de conexión a servicios internos. Una persona trabaja contra staging, otra contra local, otra contra un contenedor Docker, y todas tienen una versión distinta del mismo archivo. Si ese archivo está en el repo, conviene separar una plantilla versionada del archivo real que cada quien copia localmente.

Un patrón práctico es este:

1. Versiona un archivo base, por ejemplo config.example.json.
2. Ignora el archivo real con .gitignore, por ejemplo config.json.
3. Indica en el README cómo copiar y ajustar el archivo local.
4. Si alguien ya lo versionó por error, sácalo con git rm --cached.
5. Evita usar skip-worktree como solución permanente para todo el equipo.

Ese flujo reduce sorpresas y hace que el repo sea más predecible. Además, si alguien se une al equipo desde Ecuador, México, Colombia o Argentina, no depende de una configuración oculta en su máquina para que el proyecto funcione.

Un ejemplo realista en un proyecto Node

Supón que tu app usa estos archivos:

• .env: contiene secretos y variables locales.
• .env.example: plantilla para el equipo.
• dist/: salida del build.
• .vscode/settings.json: ajustes de editor que no todos comparten.

La regla sana sería versionar .env.example, ignorar .env, ignorar dist/ y decidir con el equipo si .vscode/settings.json se comparte o no. Si el archivo de VS Code afecta el formato o el lint de todos, sí puede ir al repo. Si solo cambia tu tema o tu extensión favorita, no debería entrar.

Errores comunes que te conviene evitar

El primer error es pensar que agregar un archivo a .gitignore lo sacará del historial. No pasa. Si ya estaba trackeado, Git seguirá viéndolo hasta que lo retires del índice. Por eso muchos equipos creen que “Git no respeta el ignore”, cuando en realidad el archivo ya estaba bajo seguimiento.

El segundo error es usar assume-unchanged o skip-worktree como parche para conflictos de diseño. Si un archivo necesita distintas versiones por entorno, probablemente no debería ser un solo archivo compartido. En ese caso, conviene separar plantilla, variables locales y documentación clara.

El tercer error es meter reglas demasiado amplias en .gitignore. Ignorar *.json porque te molesta un archivo puede romper el flujo de datos del proyecto. Ignorar config/ completo puede esconder archivos que sí deberían versionarse. Mientras más general sea la regla, más fácil es tapar un problema real.

Señales de que elegiste mal

• git status sigue mostrando archivos que creías ignorados.
• Tu compañero no ve el mismo comportamiento que tú en su máquina.
• Un pull te rompe la configuración local.
• Tienes que repetir comandos manuales cada vez que clonas el repo.

Si te pasa una de esas cosas, revisa primero si el archivo está trackeado, luego si la regla vive en el lugar correcto y, por último, si estás usando una opción local para un problema que en realidad es de equipo.

Tabla resumen

Cierre práctico para tu día a día

Si te quedas con una sola idea, que sea esta: .gitignore no es la única herramienta, pero sí debería ser tu primera opción cuando el problema es de equipo. Para todo lo que sea local y temporal, Git tiene alternativas, aunque no todas son igual de seguras ni igual de claras para colaborar.

En proyectos pequeños, esto parece un detalle menor. En proyectos con varios devs, varios sistemas operativos y varios entornos, ese detalle evita commits basura, conflictos innecesarios y tiempo perdido revisando por qué un archivo vuelve a aparecer. Si quieres trabajar más limpio, la clave no es memorizar comandos raros, sino elegir la herramienta correcta para cada tipo de archivo.

Si alguna vez dudaste entre ignorar, destrackear o esconder cambios locales, vuelve a esta regla rápida: compartido va al repo, personal va a tu máquina, y lo que ya está trackeado necesita una decisión explícita. Con eso cubres la mayoría de los casos reales sin complicarte de más.