Git no limita los patrones de ignorar a `.gitignore`. Según el artículo de Mihai Dinculescu publicado el 23 de septiembre de 2026, Git lee patrones en tres ubicaciones que comparten la misma sintaxis: los archivos `.gitignore` del repositorio, `.git/info/exclude` para el clon actual y un archivo global de exclusiones configurado mediante `core.excludesFile`.

La diferencia práctica es el alcance. Una entrada en `.gitignore` está versionada y, por tanto, llega a otras personas que clonan el repositorio, lo que la hace adecuada para productos de compilación compartidos y directorios estándar del entorno local. `.git/info/exclude` afecta únicamente a un clon y no puede incluirse en una confirmación por accidente porque reside en los metadatos internos de Git. El archivo global se aplica en todos los repositorios de una misma máquina y resulta útil para archivos generados por el editor o el sistema operativo que no deberían convertirse en una política del proyecto.

Esta distinción es importante para notas privadas, planes de agentes, scripts temporales y otros archivos útiles a nivel local pero irrelevantes para los colaboradores. Dinculescu utiliza `.git/info/exclude` para este tipo de archivos, incluso mediante comandos como `echo 'plans/' >> .git/info/exclude`. Git también puede utilizar `$XDG_CONFIG_HOME/git/ignore` o `~/.config/git/ignore` como archivo global; es posible asignar una ubicación distinta con `git config --global core.excludesFile`.

Las reglas para ignorar archivos tienen un límite importante: no impiden que archivos que ya están versionados aparezcan entre los cambios. Antes de que un patrón de exclusión pueda mantener un archivo fuera de la salida habitual de estado, ese archivo versionado debe dejar de estar versionado mediante Git. La exclusión es, por tanto, una cuestión de higiene del espacio de trabajo, no un sustituto de la gestión de secretos, los controles de acceso o una revisión cuidadosa antes de confirmar cambios.

Los árboles de trabajo vinculados añaden otra complicación. En un árbol de trabajo vinculado, `.git` puede ser un archivo que apunta al repositorio principal en lugar de un directorio que contiene `info/exclude`. Dinculescu recomienda resolver el directorio compartido de Git con `git rev-parse --git-common-dir` y añadir entradas al archivo `info/exclude` de ese directorio. El archivo de exclusiones resultante cubre los árboles de trabajo vinculados asociados con ese repositorio.

Los perfiles de GitHub y Stack Overflow suministrados identifican a Dinculescu, pero no verifican de forma independiente el comportamiento de Git descrito anteriormente; la explicación técnica procede del artículo principal. El artículo también analiza una configuración del selector de archivos de Claude Code, pero el material suministrado no incluye la documentación de configuración de referencia necesaria para resolver una discrepancia de mayúsculas en el nombre de esa opción. En cuanto a Git, sin embargo, la lección operativa central es clara: elige el archivo de exclusión según la audiencia prevista y recuerda que ocultar un archivo no versionado en `git status` no cambia si un archivo versionado forma parte del control de versiones.