Что игнорировать, а что коммитить

Хороший .gitignore оценивают не по длине, а по критерию. Критерий один: может ли человек, заново клонировавший репозиторий, получить тот же результат только из исходников и настроек? То, что можно воссоздать, игнорируется; то, что воссоздать нельзя или что фиксирует результат, коммитится.

Что игнорировать

Вид	Примеры	Причина
Артефакты сборки	`dist/`, `build/`, `target/`, `.o`, `.class`	заново собираются из исходников
Установленные зависимости	`node_modules/`, `vendor/` (PHP), `.venv/`	заново устанавливаются по манифесту и lockfile
Кэши и логи	`.cache/`, `.pytest_cache/`, `*.log`, `coverage/`	меняются при каждом запуске
Локальное окружение и секреты	`.env`, `.pem`, `local.properties`, `.tfstate`	различаются у разных людей и окружений или не должны утечь
Личное состояние инструментов	`.DS_Store`, `*.swp`, `.idea/workspace.xml`	не относятся к проекту (рекомендуется глобальный gitignore)

Что коммитить

lockfile: package-lock.json, yarn.lock, pnpm-lock.yaml, Cargo.lock, poetry.lock, uv.lock, Gemfile.lock, composer.lock, go.sum, .terraform.lock.hcl. Они обеспечивают, что все устанавливают одинаковые версии. Некоторые шаблоны, например Angular, игнорируют lockfile, поэтому проверяйте результат.
Примеры настроек: .env.example, config.example.yml. Они показывают, какие значения нужны, но не содержат настоящих секретов.
Обёртки инструментов сборки: gradlew и gradle/wrapper/, mvnw. Проверьте, не игнорируется ли jar обёртки из-за *.jar в шаблоне Java.
Согласованные в команде настройки редактора: .editorconfig, .vscode/settings.json, .vscode/extensions.json, .idea/codeStyles/. Общие настройки форматирования и линтинга упрощают ревью.

.gitignore в подкаталогах

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

repo/
├── .gitignore          # общее: .DS_Store, .env, coverage/
├── apps/web/.gitignore # .next/, out/
└── services/api/.gitignore # target/

Сохранение пустых каталогов

git отслеживает только файлы и не хранит пустые каталоги. Если, как с папкой логов, папка должна существовать, а её содержимое — игнорироваться, положите в неё файл-метку и верните его отрицающим правилом.

/log/*
!/log/.keep

Имена .keep и .gitkeep — не официальная функция git, а лишь соглашение. Работает любое имя. Другой способ — положить в эту папку .gitignore со следующим содержимым: он игнорирует всё, кроме самого себя.

*
!.gitignore

При объединении шаблонов

Обычная комбинация — 1–2 языка или фреймворка + ОС + редактор. Если правила ОС и редактора вынесены в глобальный файл, их можно опустить.
Проверяйте порядок. Шаблоны с отрицающими правилами (Gradle, VisualStudioCode) ставьте после шаблонов с широкими правилами (Java, Kotlin).
Удаляйте дубликаты, сохраняя смысл. Повторяющиеся правила не меняют поведения, но затрудняют чтение. Генератор на этом сайте удаляет дубликаты только если между ними нет отрицающего правила.
Оставляйте комментарии к разделам. Через несколько месяцев нужно понимать, откуда взялось правило, чтобы безопасно его удалить.
Тестируйте. Вставьте реальные пути, полученные через git ls-files, в тест шаблонов и убедитесь, что не игнорируются непредусмотренные файлы (например, фронтенд-код, попавший под lib/ из шаблона Python).

Правила — короткие и конкретные

Слишком широкие правила вроде *.json поглощают и файлы настроек. По возможности сужайте путь (/dist/) и ставьте завершающий слеш у каталогов, чтобы отличать их от одноимённых файлов. Однострочный комментарий с причиной над правилом поможет следующему человеку решить, можно ли его удалить.

Что игнорировать, а что коммитить