Хватит коммитить .DS_Store: глобальный git ignore, из-за которого заворачивают пул-реквесты
Мейнтейнер получает PR с добавлением мусора IDE в .gitignore проекта — и каждый раз объясняет: есть глобальный файл, который делает это один раз и для всех репозиториев. Разработчики с двадцатилетним стажем признавались: не знали.
Короткая заметка о трёх местах, где Git ищет правила игнорирования, — .git/info/exclude (локально, без коммита) и ~/.config/git/ignore (для пользователя, везде) — попала на главную HN. Одни назвали это пересказом man-страницы.
Но обсуждение превратилось в обмен приёмами, которые в заметку не вошли: .gitattributes для скрытия шума в diff вроде package-lock.json и update-index --skip-worktree для уже отслеживаемых файлов. Вывод мейнтейнера: перестаньте класть мусор своего редактора в общий .gitignore.
Три места, где Git ищет правила до того, как начать отслеживать файл

Заметка формулирует простую мысль: .gitignore — это общий, закоммиченный список, но не единственный. Есть .git/info/exclude: живёт внутри папки .git репозитория, никогда не коммитится — идеальное место для личных файлов, которые нужны только вам в этом конкретном репо. И есть глобальный файл игнорирования для пользователя — \~/.config/git/ignore (настраивается через core.excludesFile): правильное место для .DS_Store, чтобы он исчезал из каждого репозитория сразу. Там же — git check-ignore -v <file>, чтобы выяснить, какое именно правило скрывает файл. Обсуждение перевалило за 120 комментариев.
Правило, которое мейнтейнер хочет объяснить каждому
Практический результат выплыл в виде хронической боли мейнтейнера — и именно здесь глобальный файл важен.
«Ко мне регулярно приходят PR с добавлением файлов IDE/ОС/ИИ/… в .gitignore каждого проекта. Люди почти всегда приятно удивляются, когда я говорю, что их можно добавить в стандартную конфигурацию и игнорировать везде.» — мейнтейнер проекта
Масштаб проблемы оказался сюжетом сам по себе. «Я профессиональный разработчик уже 20 лет… и всю жизнь пользовался только .gitignore», — признал один из комментаторов. Другие парировали, что заметка слишком поверхностна: «очень слабое переложение» официальных gitignore docs, как выразился один из читателей.
Приёмы, которые в заметку не вошли
Настоящая ценность обсуждения — техники за пределами трёх механизмов из статьи, для случаев, когда простое игнорирование не помогает.
«Хорошая заметка, но она упускает мою любимую функцию почти-игнорирования в Git:
.gitattributes. Этот файл позволяет указать Git «игнорировать» diff определённых файлов. Например…package-lock.json— чистый шум с точки зрения Git.» — комментатор о подавлении шумных diff
Для файлов, которые Git уже отслеживает и которые .gitignore не трогает, всплыли ещё два инструмента. Один читатель указал на git update-index --skip-worktree для локальных экспериментов с закоммиченными файлами — с оговоркой, что настройка невидима и о ней легко забыть. Другой поделился алиасами для --assume-unchanged под ту же задачу.
Пересказ man-страницы, который научил кое-чему опытных разработчиков
Мета-урок — в разрыве между двумя реакциями: критики назвали это пересказом git help gitignore, а разработчики с двадцатилетним стажем признавались, что узнали что-то новое. Оба правы. Три механизма задокументированы; расширения из обсуждения — .gitattributes для шума в diff и skip-worktree для отслеживаемых файлов — и есть то, что стоит запомнить. Если вы до сих пор добавляете .idea/ и .DS_Store в каждый .gitignore, решение — один файл в домашней директории.
Получайте такие разборы каждый день
Главные истории Hacker News — на email, в Telegram или RSS.
Переехал с GNU Stow на Chezmoi — обсуждение добралось до Nix
Жалоба, которая запустила миграцию, крошечная и конкретная: симлинки работают в обе стороны, каждое редактирование сразу пишет обратно в репозиторий и незаметно делает дерево грязным. Исправление открыло 116-комментарный путь вверх по инструментальной лестнице.