Файл .gitignore

.gitignore описывает untracked paths, которые Git не должен предлагать к добавлению. Он не удаляет уже отслеживаемый файл и не является защитой секретов.

Пример для Java/Obsidian

# IDE и ОС
.idea/
*.iml
.DS_Store
 
# сборка
target/
*.log
 
# локальная конфигурация
.env
application-local.properties
 
# локальное состояние Obsidian
.obsidian/workspace*.json

Нужно решить, должна ли вся .obsidian/ быть локальной: plugins/config могут быть полезны команде, а workspace layout — обычно персонален.

Правила

*.log
/build/
cache/
!important.log

• /build/ относится к корню этого .gitignore;
• cache/ совпадает с каталогами на подходящих уровнях;
• ! возвращает path, если его parent не исключён непреодолимым правилом;
• rules во вложенном .gitignore действуют от его каталога.

Диагностика

git status --ignored
git check-ignore -v .idea/workspace.xml

Если файл уже tracked:

git rm --cached application-local.properties

Эта команда убирает его из следующего snapshot, но значение остаётся в предыдущих commits. Утекший credential нужно отозвать; очистка истории — отдельная согласованная операция.

Глобальные личные исключения можно держать вне repository через core.excludesFile, чтобы не засорять проект предпочтениями конкретной IDE.

Типичные сбои

• Добавить secret в .gitignore после commit и считать утечку закрытой.
• Игнорировать весь каталог, а затем не суметь вернуть вложенный файл через !.
• Спрятать lockfile или wrapper, нужный воспроизводимой сборке.
• Добавить слишком широкое *.json.
• Не заметить tracked файл, потому что он больше не показывается как untracked.

Вопросы для собеседования

Действует ли .gitignore на tracked file? Нет.

Как узнать, какое правило исключило path? git check-ignore -v path.

Удаляет ли git rm --cached файл с диска? Нет, он удаляет path из index; working copy остаётся.

Можно ли хранить секрет, если файл ignored? Это снижает шанс случайного add, но не защищает файл и не отменяет secret management.

См. Что такое Git, Как я веду и публикую JavaNotes.