Три способа скрыть файлы в Git вместо .gitignore

В Git есть три способа скрыть файлы от отслеживания, и разработчики часто знают только про .gitignore. На самом деле каждый уровень решает свою задачу: .gitignore попадает в репозиторий и унифицирует правила для всей команды; .git/info/exclude живёт локально, не синхронизируется и подходит для личных файлов вроде notes.txt; ~/.config/git/ignore действует глобально на всей машине и удобен для операционных артефактов типа .DS_Store на macOS.

Для диагностики есть команда git check-ignore -v, которая показывает, какой из трёх файлов именно блокирует конкретный файл. Кроме того, в ~/.config/git/ignore можно переопределить путь через git config --global core.excludesFile, если нужна своя глобальная схема именования.

Ключевые факты

.gitignore попадает в репозиторий и синхронизируется между членами команды
.git/info/exclude работает локально и не отправляется на сервер
~/.config/git/ignore применяется глобально ко всем репозиториям на машине
git check-ignore -v показывает, какой файл блокирует конкретный файл
Глобальный ignore-файл можно переименовать через core.excludesFile

Ред. Три уровня вложенности это выглядит как плохой дизайн, но на самом деле просто эволюция требований.

Почему это важно

Разработчик, не знающий про .git/info/exclude и глобальный ignore, часто делает одно из двух: либо закоммитивает личные артефакты (notes.txt, конфиги IDE) в .gitignore и загромождает общий файл, либо добавляет их в .gitignore, потом перестаёт коммитить, когда другой разработчик удалит эту строку. Уровни игнорирования решают проблему разделения ответственности: локальное остаётся локальным, операционное остаётся на машине, командное синхронизируется.

Ред. Если в вашем .gitignore полно IDE-артефактов, вы уже пересекали границу между слоями.

Кому это важно

Одиночкам это пригодится при переходе на новую машину: вместо копирования .gitignore из каждого проекта достаточно один раз настроить ~/.config/git/ignore с операционными правилами. Командам это помогает разделить видимость: team lead устанавливает общие правила в .gitignore, разработчик может добавить личные пути в .git/info/exclude без угрозы конфликта. Автоматизации (CI/CD, deploy-скрипты) полагаются на консистентность .gitignore по всем машинам.

Ред. Если в команде нет .gitignore, это не отсутствие проблемы, а отсутствие контроля над её масштабом.

Как это применить

Для локального репозитория: если появился файл, который нужен только вам (заметки, локальный .env), добавьте его в .git/info/exclude. Для глобального правила: настройте ~/.config/git/ignore с типичными артефактами вашей ОС и IDE (например.DS_Store, node_modules.vscode.idea). Для команды: держите .gitignore чистым, добавляя туда только то, что актуально всем. Чтобы проверить, какой файл блокирует specific файл, используйте git check-ignore -v filename, инструмент покажет точный источник правила.

Ред. git check-ignore, это та команда, о которой узнают в разговоре на собеседовании, но используют один раз в жизни.

Можно ли доверять

Автор Нельсон, разработчик с опытом, опирается на официальную документацию Git, которая эти три механизма описывает ясно. Команда git check-ignore проверена десятилетиями использования в экосистеме. Синтаксис игнорирования (glob-patterns) остаётся стабильным со времён .gitignore. Единственное ограничение: правила игнорирования работают только на файлы, которые ещё не в истории репозитория; если файл уже закоммичен, игнорирование его не удалит.

Ред. Если забыли про .git/info/exclude и уже добавили password.txt в .gitignore, удаляйте из истории, потом игнорируйте.

Риски и подводные камни

Первый подвох: .git/info/exclude не синхронизируется, и новый разработчик, склонировавший репозиторий, не будет знать о локальных исключениях. Если это важно для workflow, нужна документация. Второе: разные разработчики могут случайно использовать разные глобальные файлы игнорирования (если не договориться о имени) и загромождать общий .gitignore своими артефактами. Третье: glob-синтаксис в игнорировании может быть неожиданным (например, /notes.txt игнорирует файл только в корне, а notes.txt везде). Четвёртое: если в раннюю версию проекта случайно попал node_modules или .env, добавление его в .gitignore не удалит из истории, нужно использовать git filter-branch или BFG для очистки.

Ред. Легче предотвратить попадание артефакта в репозиторий, чем вытаскивать его из истории потом.