Инвертируем .gitignore: игнорируем всё по умолчанию

Странно, что довольно многие разработчики дают советы, которые, похоже, исходят из мира, где они работают в одиночку, не работали с достаточным количеством людей или с достаточным количеством проектов. В данном случае `.gitignore_global` заботится об обычных подозреваемых, которых он упомянул: `.DS_Store файлы, конфигурация IDE, сжатые файлы и т.д.`. Даже если что-то пойдёт не так, это обычно обнаруживается во время первоначального скаффолдинга, до того как попадут критически важные файлы. Если вы работаете с новыми, молодыми, начинающими разработчиками, дайте им типичный урок о глобальном gitignore, локальном, конфигурации, и о том, что нужно иметь dotfiles и т.д. Дайте им свой как вдохновение или отправную точку. Редактирование: Я знаю, что мои dotfiles не лучшие в интернете, но это помогло мне легко переключаться между несколькими устройствами, несколькими личностями (работа, проекты, личное и т.д.). Недавно я почистил их и добавил автоматизацию, тесты и т.д. с помощью Claude Code. https://github.com/brajeshwar/dot

А как насчёт того, чтобы просто научиться правильно использовать `git add`? Вы так привержены тому, чтобы постоянно использовать `git add -A`? Не сложно иметь незакоммиченные файлы в вашем рабочем дереве, вообще не трогая .gitignore.

Я не игнорирую по умолчанию, а только добавляю в индекс те элементы, которые явно хочу. Не могу сказать, сколько раз я работал в паре с кем-то, когда они просто говорят «git add .», и я всегда смущён этим выбором. Я понимаю, но я видел больше проблем, возникающих из-за добавления всего, чем из-за последовательного выборочного подхода. Каждому своё.

> прочий мусор (например, CLAUDE.md), который не должен быть в вашем репозитории

Как CLAUDE.md/AGENTS.md может быть «мусором, который не должен быть в вашем репозитории»? Если вы используете агентов для проекта и у вас есть некоторые специфические для проекта правила для них, почему бы вы хотели, чтобы другие люди, использующие агентов в вашем репозитории, не имели доступа к этим правилам и создавали код хуже?

Очень подход в духе инженера по безопасности. Я блокирую все порты на VPS, затем открываю по одному. Тот же подход здесь с файлами. Единственный недостаток, который я здесь вижу, — это знание того, что разрешить. С портами это легко, но файлы могут иметь множество различных расширений. Приложения/CLI и т.д. создают файлы с расширениями, с которыми вы никогда не сталкивались, что может вызвать проблемы. Кроме этого, мне нравится подход.

Я не убеждён в игнорировании всего, но одно из лучших изменений, которые я когда-либо вносил в свой git-процесс, — это игнорирование всех dotfile-ов по умолчанию, добавив `.*` в ~/.config/git/ignore. Теперь в моих проектах должен быть шаблонный код для снятия игнорирования с обычных файлов (!.gitignore, !.gitattributes, !.github, !.editorconfig и т.д.), но затем я могу в любой момент бросить файлы .foo.lang, или каталоги .tmp/.cache, или помощники Claude, такие как .code_analysis.md, или .todos.txt, или что угодно в мой проект, не управляя последствиями забывания обновить .gitignore. Я удивлён, что больше людей не идут этим путём.

Проблема этого подхода (которую их первый пример уже демонстрирует) в том, что вы почти сразу начнёте с решения «файлы такого типа — ок», и то, должно ли что-то попадать в git, на самом деле не имеет очень сильной корреляции с типом файла. Это мешает `git status` и по сути заставляет вас самостоятельно отслеживать, что вы изменили (поскольку игнорируемые файлы не будут там отображаться), и это может внушить ложное чувство безопасности, что `git add .` безопасен, когда это может быть не так.