Игнорирование файлов в Git: типичные грабли и решения

Вы добавили .env в .gitignore, но Git продолжает показывать изменения. Обычно дело не в том, что правило «не работает»: файл уже попал в индекс, маска совпала не с тем путём или более позднее правило отменило игнорирование. Разберём эти случаи на Git 2.x: как проверить, какое правило сработало, и перестать отслеживать файл, не удаляя его с компьютера.

Сначала выясните, что именно показывает Git

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

Проверьте статус и спросите Git, какое правило влияет на конкретный путь:

git status --short
git check-ignore -v --no-index -- .env

Ключ -v помогает увидеть источник и строку правила, а --no-index позволяет проверить совпадение, даже если файл уже отслеживается. Если команда ничего не вывела, это ещё не доказывает, что путь игнорируется: проверьте написание и расположение файла, а затем посмотрите, не отслеживается ли он уже.

Четыре причины, почему правило не срабатывает

Файл уже отслеживается

Это самая частая ловушка. Если файл был добавлен через git add и попал в коммит, Git продолжит учитывать его изменения. Правило в .gitignore влияет на дальнейшее добавление неотслеживаемых файлов, но не вынимает уже добавленный файл из индекса.

Чтобы перестать отслеживать файл, сохранив его в рабочей папке, используйте:

git rm --cached -- .env
git commit -m "Stop tracking local environment file"

Для каталога добавьте рекурсивный ключ: git rm --cached -r -- путь/к/каталогу. Перед коммитом проверьте git status: в изменениях должен быть файл, удалённый из репозитория, но он должен остаться на диске. Не запускайте обычный git rm, если хотите сохранить локальную копию: без --cached команда удалит её из рабочей папки.

Если в файле уже были пароли или ключи доступа, удаление из текущей версии репозитория не стирает их из прошлых коммитов и копий. Сначала отзовите или смените секрет, затем отдельно разберитесь с историей репозитория.

Маска означает не то, что вы ожидали

Правило debug.log совпадает с таким именем на разных уровнях дерева, а /debug.log ограничено каталогом, где лежит конкретный .gitignore. Запись logs/ игнорирует каталоги с таким именем относительно расположения файла правил. Символ * не захватывает разделитель каталогов: поэтому logs/*.log подходит для файлов в logs/, но не для вложенного пути вроде logs/archive/old.log.

Правило в корневом .gitignore и правило в src/.gitignore считаются относительно разных каталогов. Если шаблон кажется правильным, скопируйте точный путь из вывода git status --short и проверьте его командой git check-ignore -v --no-index -- -- путь — двойной разделитель перед путём нужен, когда имя начинается с дефиса. В обычном случае достаточно git check-ignore -v --no-index -- путь.

Правило отменено другим правилом

В одном файле можно отменить игнорирование префиксом !. Например, сначала игнорировать содержимое config/, а затем разрешить конкретный пример файла. Но Git не может включить файл, если его родительский каталог целиком скрыт правилом: сам каталог тоже должен оставаться доступным для обхода.

config/*
!config/example.yml

Такой шаблон оставляет каталог видимым, игнорирует его содержимое и разрешает файл example.yml. Если же перед ним стоит правило config/, Git не сможет добраться до вложенного файла для отмены игнорирования. Порядок и расположение правил имеют значение; команда git check-ignore -v покажет конкретное совпадение.

Правило лежит не там или действует не для всех

Обычно проектные правила хранят в .gitignore и коммитят вместе с кодом: их получают все участники. Для локальных исключений только в этом клоне есть .git/info/exclude. Глобальный файл исключений Git подходит для редакторских временных файлов и настроек конкретного пользователя, но не для договорённостей проекта.

Если коллега видит файл, который у вас скрыт, сравните не только проектный .gitignore, но и локальные настройки исключений. Глобальные правила не попадут в коммит и могут скрыть мусор у вас, оставив его видимым остальной команде.

Как выбрать место для правила

Рабочая проверка перед коммитом

1. Проверьте путь. Запустите git status --short и найдите точное имя файла. Результат: вы видите путь относительно корня репозитория, а не угадываете его по имени.
2. Найдите совпавшее правило. Выполните git check-ignore -v --no-index -- путь/к/файлу. Результат: Git указывает файл с правилом и строку, если маска совпала.
3. Если правило совпало, проверьте отслеживание. Выполните git ls-files -- путь/к/файлу. Результат: пустой вывод означает, что Git не отслеживает этот путь; если путь напечатан, файл уже в индексе.
4. Если файл отслеживается, уберите его из индекса. Запустите git rm --cached -- путь/к/файлу. Результат: файл исчезает из списка отслеживаемых, но остаётся в рабочей папке.
5. Проверьте будущий коммит. Выполните git status и просмотрите изменения. Результат: в коммит попадёт удаление файла из репозитория и, если нужно, новое правило; локальная копия сохранится.

Команды приведены для Git 2.x; описанное поведение файлов исключений и git check-ignore относится к документации Git этой ветки. Перед коммитом особенно внимательно проверьте пути после команды с git rm: она меняет индекс, а обычный вариант без --cached меняет и рабочую папку.

Если Git уже знает о файле, новое правило не заставит его забыть. Сначала проверьте индекс, затем решайте, нужно ли удалить файл из него или исправить маску.

Где этот подход ломается

• Добавили секрет в историю. .gitignore защищает от случайного добавления в будущем, но не очищает старые коммиты и копии репозитория. Смените секрет и оценивайте историю отдельно.
• Разрешили файл внутри игнорируемого каталога. Правило с ! не сработает, если Git уже исключил родительский каталог. Перепишите шаблон так, чтобы Git мог пройти к нужному файлу.
• Записали слишком широкую маску. Шаблон вроде *.log может скрыть журналы в разных каталогах. Уточните его привязкой к каталогу, если исключать нужно только конкретное место.
• Убрали файл из индекса, но не добавили правило. Следующее изменение может снова предложить добавить его в коммит. Проверьте, что правило покрывает путь, и проверьте результат через git check-ignore.

Термин. Индекс Git — подготовленная область изменений между рабочими файлами и коммитом. Команда git rm --cached убирает файл именно из этой области и будущего состояния репозитория, не удаляя локальную копию.

Что делать дальше

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