Когда файл неожиданно попадает в Git или, наоборот, исчезает из списка новых файлов, начните с git check-ignore -v. Команда показывает, какое правило сработало и откуда оно взято. На Mentoring.digital разберём диагностику без удаления файлов и переписывания истории.
Узнать источник конкретного правила
git check-ignore -v -- debug.logДопустим, в корневом .gitignore первая строка содержит *.log, а debug.log ещё не отслеживается. Вывод будет иметь такой смысл:
.gitignore:1:*.log debug.logСлева указаны файл правил, номер строки и шаблон; справа проверяемый путь. Между шаблоном и путём команда использует табуляцию. Это позволяет исправить нужный источник, а не добавлять всё новые исключения наугад. Правило может находиться и в другом источнике исключений, а не только в открытом вами .gitignore.
Важная деталь: при -v показывается совпавший шаблон. Если он начинается с !, это отрицание, которое возвращает путь из исключений. Поэтому читайте сам шаблон, а не трактуйте любое непустое сообщение как доказательство игнорирования.
Почему уже отслеживаемый файл не исчезает
Правила игнорирования не прекращают отслеживание файлов, которые уже находятся в индексе. Проверьте это отдельно:
git ls-files --error-unmatch -- tracked.log
git check-ignore -v -- tracked.log
git check-ignore -v --no-index -- tracked.logПервая команда проверяет наличие пути в индексе. По умолчанию check-ignore не показывает отслеживаемые файлы. Вариант --no-index позволяет увидеть совпадение с правилом, не учитывая этот факт. Он ничего не удаляет и не прекращает отслеживание.
Если правило совпадает только при такой проверке, проблема может быть не в синтаксисе .gitignore, а в том, что файл уже добавлен. Решение о прекращении отслеживания принимайте отдельно: оно меняет состав репозитория и должно учитывать работу команды. Диагностическая команда не является командой исправления.
Как прочитать код завершения
Для обычной проверки без отрицательных шаблонов код 0 означает, что найден игнорируемый путь, 1 что такого пути среди переданных нет, 128 сообщает о фатальной ошибке. Не считайте пустой вывод универсальным признаком ошибки: это может быть нормальный результат проверки.
Для анализа отрицаний ориентируйтесь также на показанный шаблон. При автоматической обработке большого числа путей доступны --stdin и разделитель NUL через -z; разбор строк по пробелам ненадёжен, потому что имена файлов могут их содержать.
Безопасный порядок диагностики
- Проверьте точное имя и путь относительно текущего репозитория.
- Запустите
check-ignore -vи прочитайте источник, строку и шаблон. - Если вывода нет, отдельно проверьте индекс через
ls-files. - Для отслеживаемого файла сравните результат с
--no-index. - Меняйте конкретное правило только после выяснения причины.
Не начинайте с очистки всего индекса или массового удаления: для объяснения поведения это не требуется. Если в проекте пересекаются правила нескольких каталогов, их можно разобрать с наставником по Git. Пример с обычным и уже отслеживаемым .log-файлом проверен в отдельном временном репозитории.
