RUENЗагрузить файл
Инструменты · Разработка

Что такое .gitignore и как его правильно настроить

.gitignore — служебный файл проекта, который говорит Git, какие файлы и папки не трогать: не отслеживать, не предлагать добавить в коммит и не показывать в выводе git status. Без него разработчик рано или поздно случайно коммитит то, чего в репозитории быть не должно, — например, файл .env с паролями (о нём мы подробно писали в статье «Что такое ENV-файл»), папку зависимостей или локальные логи. Разбираем синтаксис правил, готовые шаблоны под разные языки и типичные ошибки при работе с .gitignore.

Коротко: .gitignore — текстовый файл в репозитории Git со списком паттернов (масок) файлов и папок, которые Git должен игнорировать. В него обычно попадают зависимости (node_modules), скомпилированные файлы, логи, локальные настройки и секреты вроде .env. Правила действуют только на ещё не отслеживаемые файлы — уже закоммиченный файл .gitignore сам по себе не удаляет и не скрывает.

Опубликовано: 21 октября 2026 Редакция Loadfile Чтение 12 мин
Что такое .gitignore и как его правильно настроить
Содержание
  1. Что такое .gitignore и зачем он нужен
  2. Как создать .gitignore: три способа
  3. Синтаксис правил: что значат *, **, ! и /
  4. Проектный, локальный и глобальный .gitignore: что главнее
  5. Готовые шаблоны: Python, Node.js, Java, Go
  6. Файл уже закоммичен: как перестать его отслеживать
  7. Как добавить в репозиторий пустую папку (.gitkeep)
  8. Как проверить, почему файл игнорируется
  9. Частые ошибки при работе с .gitignore
  10. Вопросы и ответы

Что такое .gitignore и зачем он нужен

.gitignore — это обычный текстовый файл, который Git читает перед тем, как показать вам список изменённых и новых файлов. Каждая строка в нём — паттерн (маска), описывающий файл, папку или группу файлов по имени, пути или расширению. Всё, что подходит под один из паттернов, Git перестаёт предлагать добавить в коммит: такие файлы не появляются в git status, не попадают под git add . и не уходят в историю репозитория.

Файл кладётся в корень проекта рядом с папкой .git и называется ровно .gitignore — с точкой в начале и без расширения после «gitignore». Технически без него можно обойтись: Git прекрасно работает и без .gitignore, просто тогда отслеживать или не отслеживать каждый файл приходится вручную.

Проблема в том, что без .gitignore в репозиторий рано или поздно попадает лишнее. Самые частые случайные гости в коммитах: папка зависимостей (node_modules в JavaScript-проектах, venv в Python), скомпилированные и временные файлы, логи приложения, служебные файлы операционной системы (.DS_Store на macOS, Thumbs.db на Windows) и, в худшем случае, файл .env с реальными паролями и API-ключами. Если такой файл уже в истории Git, удалить его оттуда — отдельная и не всегда простая задача (см. блок «Файл уже закоммичен» ниже).

Как создать .gitignore: три способа

Создать файл можно за минуту — вопрос только в том, писать ли правила с нуля или взять готовые.

  1. Вручную. В корне проекта создайте файл с именем .gitignore — через терминал (touch .gitignore на macOS/Linux, type nul > .gitignore в Windows PowerShell) или через проводник/файловый менеджер IDE. На Windows обычному «Проводнику» иногда не даёт создать файл без имени до точки — в таком случае проще сделать это через терминал или редактор кода.
  2. Из готового шаблона с GitHub. Официальный репозиторий github/gitignore содержит проверенные шаблоны почти для всех популярных языков и фреймворков — Python, Node, Java, Go, Unity и десятки других. Проще всего скопировать содержимое нужного файла целиком и доработать под свой проект.
  3. Через онлайн-генератор. Сервисы вроде gitignore.io позволяют выбрать технологии проекта (например, «Node», «macOS», «VisualStudioCode») и получить готовый .gitignore, который объединяет шаблоны для всех выбранных пунктов — удобно, когда стек состоит из нескольких языков и инструментов сразу.
i
Создавайте .gitignore до первого коммита

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

Синтаксис правил: что значат *, **, ! и /

Каждая строка .gitignore — отдельный паттерн. Несколько символов в нём имеют особое значение, и путаница между ними — частый источник того, что «правило не работает».

ПаттернЧто игнорируетПример
*Любые символы в пределах одного уровня пути (не заходит в подпапки)*.log — все файлы с расширением .log в той же папке
**Любое количество вложенных папок, на любую глубину**/temp — любая папка temp на любом уровне вложенности
!Исключение — отменяет игнорирование для конкретного файла внутри уже проигнорированного правила!important.log — не игнорировать этот файл, даже если выше есть *.log
/ в начале строкиПуть строго от корня репозитория, а не от любой вложенной папки/build — только папка build в корне, но не src/build
/ в конце строкиТолько папка с этим именем, но не одноимённый файлlogs/ — игнорирует папку logs, но не файл logs без расширения
?Ровно один произвольный символfile?.txt — совпадёт с file1.txt, fileA.txt, но не с file10.txt
[abc]Один символ из перечисленных в скобкахlog[0-9].txt — log0.txt … log9.txt
# в начале строкиКомментарий — не паттерн, Git строку игнорирует# временные файлы сборки

Полный и точный список правил описан в официальной документации Git по .gitignore — стоит сверяться с ней, если сомневаетесь, как поведёт себя конкретное сочетание символов.

!
«!» работает не всегда

Если паттерн выше по файлу игнорирует всю родительскую папку целиком (например, build/), строка !build/keep.txt ниже НЕ вернёт файл обратно — Git не заходит внутрь уже проигнорированной директории, чтобы проверить исключения. Чтобы «!» сработал, игнорировать нужно не саму папку, а файлы внутри неё по маске.

Проектный, локальный и глобальный .gitignore: что главнее

У Git есть не один, а сразу несколько уровней, на которых можно описать игнорируемые файлы — и у них разный охват и разное назначение.

  • Проектный .gitignore — файл в корне репозитория, который коммитится вместе с кодом и общий для всей команды. Это основное место для правил проекта: зависимости, сборка, кэш инструментов.
  • Вложенные .gitignore — отдельный файл .gitignore можно положить и в подпапку: его правила применяются только внутри неё и её вложенных директорий. Нужен редко — обычно когда у конкретного модуля есть своя специфика сборки, которую не хочется тащить в общий файл.
  • Глобальный .gitignore — настраивается один раз на компьютере разработчика командой git config --global core.excludesFile ~/.gitignore_global и применяется ко всем репозиториям сразу. Сюда логично выносить не связанные с конкретным проектом вещи — файлы ОС (.DS_Store, Thumbs.db) или служебные папки своего редактора кода (.idea/, .vscode/), если команда не хочет видеть их в общем проектном .gitignore.
  • .git/info/exclude — файл внутри самой папки .git, личный и не коммитится никогда, потому что не является частью репозитория. Подходит для сугубо личных исключений одного разработчика на одном проекте — например, собственных заметок в отдельном файле, которые не нужны остальной команде.

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

Готовые шаблоны: Python, Node.js, Java, Go

У каждого языка и фреймворка — свой набор типовых «мусорных» файлов и папок, которые принято игнорировать с первого коммита. Ниже — базовые, общепринятые строки для четырёх распространённых стеков; для реального проекта стоит дополнить их специфичными инструментами (линтеры, IDE, конкретный фреймворк).

# Python __pycache__/ *.pyc .venv/ venv/ *.egg-info/ .pytest_cache/
# Node.js node_modules/ dist/ build/ .env npm-debug.log* .DS_Store
# Java *.class target/ *.jar .gradle/ build/
# Go *.exe *.test vendor/ /bin/

Шаблон .gitignore с правилами игнорирования файлов

i
Не изобретайте шаблон с нуля

Для типовых стеков безопаснее не писать .gitignore вручную, а взять официальный шаблон из github/gitignore и дополнить своими несколькими строками — так меньше риск забыть что-то общеизвестное для конкретного языка или фреймворка.

Такие наборы правил — тоже частный случай заготовок проекта: подробнее о готовых стартерах и шаблонах кода — в материале шаблоны кода и boilerplate. В коммерческой веб-разработке настройка .gitignore обычно входит в стандартный чек-лист инициализации репозитория — так, например, команда YuSMP Group закладывает эти правила ещё на старте новых проектов, до первого коммита.

Файл уже закоммичен: как перестать его отслеживать

Главная путаница вокруг .gitignore: добавление файла в список правил НЕ убирает из репозитория то, что Git уже отслеживает. Правила действуют только на новые, ещё не добавленные в индекс файлы.

  1. Добавьте путь к файлу в .gitignore — чтобы он больше не попадал в коммиты после того, как вы его уберёте из отслеживания.
  2. Снимите файл с отслеживания командой git rm --cached <файл> (для папки — с флагом -r: git rm -r --cached <папка>). Это удаляет файл из индекса Git, но оставляет его на диске нетронутым.
  3. Закоммитьте изменение — с этого коммита Git перестаёт отслеживать файл, а .gitignore начинает на него действовать.
!
В истории файл всё равно останется

Описанные шаги убирают файл из будущих коммитов, но не из прошлых — все версии файла, которые уже были закоммичены, остаются в истории репозитория и доступны любому, у кого есть доступ к git log. Если в файле были секреты (как в примере с .env, о котором мы писали в статье про ENV-файл), этого недостаточно — нужно считать их скомпрометированными и менять, а переписывание истории Git — отдельная, более рискованная операция.

Как добавить в репозиторий пустую папку (.gitkeep)

У Git есть особенность, которая иногда удивляет новичков: он отслеживает файлы, а не папки как таковые. Если папка пустая, Git её попросту не видит и не включает в репозиторий — при клонировании проекта пустых директорий (например, logs/ или uploads/, которые должны существовать для работы приложения) просто не окажется на месте.

Решение — положить в такую папку файл-заглушку, по негласной договорённости называемый .gitkeep. Это не специальная функция Git, а просто пустой или почти пустой файл: раз в папке появился хоть один файл, Git начинает отслеживать и саму папку. Имя файла может быть любым — .gitkeep прижилось как читаемая конвенция, а не как зарезервированное Git-имя.

Как проверить, почему файл игнорируется

Когда файл не отслеживается, а ожидалось обратное (или наоборот), быстрее всего разобраться командой git check-ignore -v <путь-к-файлу>.

Флаг -v (verbose) выводит не только сам факт игнорирования, но и то, какой именно файл .gitignore и какая строка в нём отвечает за это — например, .gitignore:3:*.log debug.log означает, что файл debug.log игнорируется третьей строкой корневого .gitignore. Если команда ничего не выводит — значит, ни одно правило на файл не действует, и причину «файл не коммитится» нужно искать в другом месте (например, он уже в индексе как изменённый, а не новый).

Частые ошибки при работе с .gitignore

!
Правило добавлено слишком поздно

Если файл уже был закоммичен раньше, добавление его в .gitignore ничего не меняет задним числом — Git продолжает его отслеживать, пока явно не снять файл с индекса командой git rm --cached (см. блок выше).

!
Слишком общие паттерны

Правило вроде *.txt на весь проект может случайно спрятать нужные текстовые файлы — например, документацию или README-заметки в подпапках. Точечные паттерны (конкретная папка, конкретное расширение в конкретном месте через /) безопаснее широких масок на весь репозиторий.

!
Секреты без .gitignore с первого коммита

Самая дорогая ошибка — создать файл с паролями или ключами (например, .env, подробнее — в статье «Что такое ENV-файл») раньше, чем .gitignore с правилом для него. Правильный порядок — обратный: сначала .gitignore с нужными строками, и только потом файл с реальными секретами.

!
В репозитории вообще нет .gitignore

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

Вопросы и ответы

Что будет, если удалить файл из .gitignore?

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

Можно ли игнорировать всё в папке, кроме одного файла?

Да, через исключение «!» после общего правила. Но есть нюанс: если сама папка уже проигнорирована целиком (а не её содержимое по маске), «!» не сработает — Git не заходит внутрь уже исключённой директории, чтобы проверить исключения.

Почему .gitignore не действует на уже закоммиченный файл?

Потому что правила .gitignore применяются только к ещё не отслеживаемым Git файлам. Для файла, который уже в индексе, нужно сначала выполнить git rm --cached — только после этого .gitignore начнёт на него действовать.

Нужен ли отдельный .gitignore в каждой подпапке проекта?

Нет, обычно достаточно одного файла в корне репозитория. Вложенные .gitignore нужны только для специфичных для конкретной подпапки исключений, которые не хочется выносить в общий файл.

Что лучше — свой .gitignore или шаблон с GitHub?

Для типовых стеков (Python, Node.js, Java, Go и других) безопаснее взять официальный шаблон из репозитория github/gitignore и дополнить его своими строками, чем писать список с нуля и рисковать забыть общеизвестный для языка файл.

Опасно ли коммитить файл .gitignore в открытый репозиторий?

Нет, сам файл .gitignore не содержит секретов. Но его содержимое показывает, какие файлы вы скрываете от репозитория — это не замена защите действительно секретных данных, для которых всё равно нужен отдельный подход (см. статью про .env).

Читайте также