Программирование и IT

Файл .gitignore

В проекте всегда есть файлы, которым в репозитории не место — кэш, папки сборки, настройки редактора, локальные пароли. Список таких файлов держат в .gitignore, и git перестаёт предлагать их к добавлению.

Обновлено
В этой статье

Зачем он нужен#

Без списка исключений git status превращается в свалку: рядом с твоими
правками висят сотни файлов кэша, а среди них легко не заметить нужное.
Хуже другое — случайно добавленный файл с паролями или ключом попадает в
историю и уезжает на сервер вместе с коммитом.

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

Синтаксис шаблонов#

Одна строка — одно правило. Пустые строки пропускаются, строка с решёткой в
начале считается комментарием.

Шаблон Что попадает под правило
secrets.txt файл с таким именем в любой папке репозитория
*.log любые файлы с расширением log
build/ папка build и всё внутри, на любом уровне
/build только build в той же папке, где лежит сам .gitignore
docs/*.pdf pdf прямо в docs, но не в её подпапках
docs/**/*.pdf pdf в docs и во всех её подпапках
*.py[cod] файлы .pyc, .pyo и .pyd
!example.log исключение из предыдущего правила: этот файл не прятать

Правила простые, но два места стоит запомнить. Слеш внутри шаблона
привязывает его к папке файла .gitignore; без слеша шаблон ищется на
любой глубине. И восклицательный знак не работает, если спрятана вся папка
целиком: git не заходит внутрь исключённой папки и не видит, что там
что-то разрешено, — в таком случае прячут содержимое (logs/*), а потом
делают исключение.

Готовый пример#

Файл в корне проекта на Python:

__pycache__/
*.py[cod]

.venv/
venv/

.idea/
.vscode/
.DS_Store

/dist/
/build/
*.egg-info/

.env
*.local.yml

*.log
!example.log

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

Заготовки для десятков языков и сред собраны в открытом репозитории
github/gitignore — брать оттуда и дописывать своё быстрее, чем
вспоминать всё с нуля.

Файл уже в репозитории, а правило не действует#

Самая частая жалоба. .gitignore работает только для неотслеживаемых
файлов; если файл однажды попал в коммит, git продолжит следить за ним,
сколько правил ни добавь. Нужно снять его с учёта, оставив на диске:

git rm --cached .env

rm '.env'

Для папки — то же самое с -r: git rm --cached -r .idea. Дальше
изменение фиксируют коммитом, и с этого момента правило действует.

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

Где ещё живут правила#

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

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

git config --global core.excludesFile ~/.gitignore_global

А правила, нужные только в этой копии репозитория и никому больше, пишут в
.git/info/exclude — он не коммитится и на сервер не уезжает.

Как проверить правило#

Когда непонятно, почему файл прячется (или не прячется), спрашивай
напрямую:

git check-ignore -v .venv/bin/python

.gitignore:4:.venv/	.venv/bin/python

Ответ читается так: источник правила, номер строки, сам шаблон и путь.
Пустой ответ означает, что под правила файл не подпадает. Посмотреть весь
спрятанный список целиком помогает git status --ignored.

Если правило написано верно, а файл всё равно виден в git status, почти
наверняка он уже отслеживается — возвращайся к git rm --cached и
коммиту через git commit. Прочие команды на каждый
день перечислены в шпаргалке.

План по этапам

  1. Создать файл в корнеОбычный текстовый .gitignore рядом с папкой .git.
  2. Внести очевидноеКэш языка, папки сборки, окружение, настройки редактора, локальные секреты.
  3. Проверить выводgit status: лишнего в списке неотслеживаемых больше нет.
  4. Снять с учёта староеgit rm --cached для файлов, попавших в репозиторий раньше правила.
  5. Закоммитить сам файл.gitignore — часть проекта и нужен всем участникам.

Начать изучать эту тему у себя

План ляжет в твой репозиторий: отмечай этапы, веди конспект — история изменений покажет, как ты продвинулся.

Начать план

Проверь себя

1.Файл .env попал в репозиторий раньше, правило в .gitignore добавили. Что ещё нужно сделать?

2.Что прячет строка build/ в .gitignore?

3.Какая команда покажет, какое именно правило прячет файл?

Источники

Было полезно?

Ещё темы

Программирование и IT Python: чтение файла Работа с файлом состоит из трёх шагов: открыть, прочитать или записать, закрыть. Закрытие лучше не делать руками — для этого есть оператор `with`. А главный параметр, про который забывают, — кодировка: без неё один и тот же код на разных машинах читает файл по-разному. Программирование и IT Как изучить Python с нуля Python хорош для первого знакомства с программированием: код читается почти как текст, а стандартная библиотека закрывает большинство бытовых задач. Этот план ведёт от установки интерпретатора до собственных скриптов, покрытых тестами, — примерно за четыре месяца при занятиях около часа в день. Программирование и IT Как изучить SQL с нуля SQL — язык запросов к реляционным базам данных. Он нужен разработчикам, аналитикам, тестировщикам и менеджерам, которые хотят сами доставать цифры. Базовые запросы осваиваются за несколько недель, уверенная работа со сложными отчётами — за два-три месяца практики. Ниже — порядок тем и способы тренироваться на настоящей базе. Программирование и IT Как изучить Linux с нуля Linux работает на большинстве серверов, в контейнерах и на множестве устройств, поэтому командная строка нужна разработчику, тестировщику, аналитику и системному администратору. Осваивать систему удобнее всего не чтением списков команд, а ежедневной работой в терминале и решением небольших практических задач. Ниже — последовательность тем на два-три месяца. Программирование и IT Как изучить JavaScript с нуля JavaScript — язык, который исполняется в каждом браузере, а через Node.js ещё и на сервере. У него низкий порог входа — код можно запустить прямо в консоли браузера, — но много неочевидных мест, от приведения типов до асинхронности. План ниже рассчитан на три-четыре месяца и предполагает, что ты уже знаешь основы HTML и CSS или изучаешь их параллельно. Программирование и IT Как изучить Java с нуля Java — строго типизированный язык, на котором написаны банковские системы, серверы крупных сервисов и Android-приложения. Строгость поначалу замедляет, зато компилятор ловит многие ошибки до запуска. Этот план рассчитан примерно на полгода занятий по часу в день и ведёт от первой программы до небольшого серверного приложения.

Ещё сценарии

Портфолио программиста Работодатель смотрит портфолио пару минут. За это время он должен понять, что ты умеешь, как пишешь код и доводишь ли дело до конца. Лучше всего это показывают несколько законченных проектов с понятными README и честной историей работы. Личная база знаний Личная база знаний — это не архив всего прочитанного, а набор твоих собственных записей, связанных между собой, к которым ты возвращаешься. Разберём, как её устроить, чтобы она работала, а не превратилась в свалку ссылок. СДО для сотрудников Классическая СДО — это курсы, назначения, отчёты и сертификаты. Skillok закрывает часть этих задач иначе — через репозиторий материалов, задачи-назначения и курсы с автопроверкой. Если тебе нужны отчёты по каждому сотруднику и совместимость со SCORM — честно скажем сразу, этого нет.