Git умеет игнорировать файлы не только через .gitignore: три уровня защиты от мусора в репозитории

Если вы работаете с Git, .gitignore для вас — привычная табличка у входа в репозиторий: сюда нельзя, туда нельзя, node_modules и .env оставьте за дверью. Но Git умеет фильтровать нежелательные файлы на трёх уровнях — и только один из них версионируется вместе с кодом. Остальные два спасают, когда правила общие не подходят: личные заметки, локальные скрипты, артефакты операционной системы.

Игнорирование в Git — это не магия, а просто набор шаблонов. Когда вы запускаете git status, Git сверяет имена файлов с тремя списками и решает, показывать их или нет. Важно: игнорируемый файл всё ещё лежит в рабочей директории, просто Git не предлагает его добавить в индекс.

Три файла, которые говорят Git «не замечай»

Каждый из трёх файлов отвечает за свой масштаб. Отличаются они не синтаксисом — он везде одинаковый, — а областью действия и тем, попадают ли изменения в историю репозитория.

.gitignore — общие правила репозитория

Это классика. Файл лежит в корне проекта или в подкаталогах, попадает под контроль версий и работает одинаково у всех, кто клонирует репозиторий. Сюда стоит писать всё, что относится к проекту целиком: зависимости, сборочные артефакты, локальные конфиги IDE, тестовые базы.

			# .gitignore
node_modules/
.env
__pycache__/
*.log
.idea/
.vscode/
dist/
build/
		

Плюс очевиден: все члены команды видят одни и те же правила. Минус тоже очевиден: если правило нужно только вам, каждый раз править общий .gitignore и создавать коммит — избыточно.

.git/info/exclude — личные правила для одного репозитория

Внутри каталога .git каждого клона есть файл info/exclude. Он устроен так же, как .gitignore, но не входит в коммиты. Это идеальное место для файлов, которые есть только у вас: черновики, личные заметки, экспериментальные скрипты, локальные дампы.

			# .git/info/exclude
# Личные заметки по проекту
notes.txt

# Локальный скрипт для бэкапа
backup-local.sh

# Мой экспериментальный конфиг
config.dev.local.yml
		

Сценарий простой: вы держите в репозитории файл notes.txt с личными пометками. Добавлять его в .gitignore не хочется — коллегам он не нужен, а в .git/info/exclude он исчезает из git status только на вашей машине.

~/.config/git/ignore — глобальные правила для всей машины

Третий уровень действует на все репозитории текущего пользователя. Если у вас macOS, вы наверняка устали видеть .DS_Store в выводе git status. Вместо того чтобы добавлять его в каждый .gitignore, проще вынести на глобальный уровень.

			# ~/.config/git/ignore
.DS_Store
Thumbs.db
*.swp
*~
.nova/
.zed/
		

Путь к глобальному файлу можно переопределить. Например, чтобы использовать .gitignore_global в домашней директории, выполните:

			git config --global core.excludesFile ~/.gitignore_global
		

Вернуть значение по умолчанию можно командой git config --global --unset core.excludesFile.

Как проверить, кто именно игнорирует файл

Когда правил много, легко забыть, какой файл за что отвечает. Git предоставляет команду git check-ignore -v, которая показывает источник игнорирования: название файла с правилами, номер строки и сам шаблон.

			$ git check-ignore -v .DS_Store
/Users/alice/.config/git/ignore:2:.DS_Store	.DS_Store
		

Если файл игнорируется .gitignore, вывод будет начинаться с .gitignore; если локальным exclude — путь к нему; если глобальным ignore — путь в домашней директории. Если команда ничего не выводит, значит файл никто не игнорирует.

Полезно:
git check-ignore работает и с каталогами. Передайте путь к папке, чтобы узнать, почему она не попадает в индекс.

Когда какой уровень использовать

• .gitignore — правила, общие для всей команды: зависимости, сборочные артефакты, секреты.
• .git/info/exclude — персональные файлы внутри одного репозитория, которые не должны светиться в коммитах.
• ~/.config/git/ignore — файлы ОС и редактора, которые мешают в любом проекте на вашей машине.

Главный принцип: чем шире правило, тем реже его стоит менять. Глобальный ignore настраивается один раз при настройке рабочей машины, а .gitignore живёт вместе с проектом и развивается вместе с ним.

Выводы

Git предлагает не один, а три уровня игнорирования, и каждый решает свою задачу. .gitignore отвечает за командные договорённости, .git/info/exclude — за личный порядок в одном репозитории, а ~/.config/git/ignore — за чистоту рабочей машины в целом. Разделение уровней помогает не засорять общие правила личными исключениями и не тащить в коммиты то, что нужно только вам.

Хороший .gitignore защищает команду, а правильное использование exclude и global ignore защищает ваше собственное ментальное здоровье при работе с кодом.

Нельсон Амейнтуавтор блога nelson.cloud

Источник: Nelson Ameyin, «.gitignore isn’t the only way to ignore files in Git».

Попробуйте проверить свои репозитории: запустите git check-ignore -v на паре подозрительных файлов — возможно, вы найдёте правила, про которые давно забыли.