Несколько `.gitignore`s хмурится?

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

Я могу вспомнить как минимум две ситуации, когда вы хотите иметь несколько .gitignoreфайлов в разных (под) каталогах.

• Различные каталоги имеют разные типы файлов для игнорирования. Например, .gitignoreв верхнем каталоге вашего проекта игнорируются сгенерированные программы, а Documentation/.gitignoreигнорируется сгенерированная документация.

• Игнорировать данные файлы только в данной (под) директории (вы можете использовать /sub/fooв .gitignore, хотя).

Помните, что шаблоны в .gitignoreфайле рекурсивно применяются к (под) каталогу, в котором находится файл, и ко всем его подкаталогам, если шаблон не содержит '/' (например, шаблон nameприменяется к любому файлу с именем nameв данном каталоге и ко всем его подкаталогам, в то время как /nameк файлу с этим именем только в данном каталоге).

В качестве тангенциального примечания, один случай, когда возможность иметь несколько .gitignoreфайлов очень полезна, - это если вам нужен дополнительный каталог в вашей рабочей копии, который вы никогда не намереваетесь зафиксировать. Просто поместите 1-байт .gitignore(содержащий только одну звездочку) в этот каталог, и он никогда не будет отображаться в git statusи т. Д.

Вы можете иметь несколько .gitignore, каждый из которых, конечно, в своем собственном каталоге.
Чтобы проверить , какая gitignore правило отвечает за игнорирование файлов, использование git check-ignore: git check-ignore -v -- afile.

И у вас может быть другая версия .gitignoreфайла для каждой ветви: я уже видел такую ​​конфигурацию для обеспечения того, чтобы одна ветвь игнорировала файл, а другая - нет: посмотрите этот вопрос, например .

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

Обратите внимание, что начиная с git 1.8.2 (март 2013 г.) вы можете сделать a git check-ignore -v -- yourfile, чтобы увидеть, какой запуск gitignore (из какого .gitignoreфайла) применяется к ' yourfile', и лучше понять, почему указанный файл игнорируется.
Смотрите " какое gitignoreправило игнорирует мой файл? "

Про сингл

• Легко найти.

• Выследить правила исключения может быть довольно сложно, если у меня есть несколько gitignore, на нескольких уровнях в репо.

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

Pro несколько

• Области "знания" к той части дерева файлов, где это необходимо.

• Поскольку Git отслеживает только файлы, пустой .gitignore - единственный способ зафиксировать «пустой» каталог.

  (И до Git 1.8 единственным способом исключить шаблон, как my/**.exampleбыло, было создание my/.gitignoreс шаблоном **.foo. Эта причина теперь не применима, как вы можете /my/**/*.example.)

Я предпочитаю один файл, где я могу найти все исключения. Я никогда не пропускал каталоги .svn, и я не буду пропускать каталоги .gitignore.

Тем не менее, несколько gitignores довольно распространены. Если вы используете их, по крайней мере, будьте последовательны в их использовании, чтобы сделать их разумными для работы. Например, вы можете поместить их в каталоги только одного уровня от корня.

Есть много ситуаций , где вы хотите , чтобы совершить каталог в Git репо , но без файлов в нем, например , в logs, cache, uploadsкаталогах и т.д.

Поэтому я всегда добавляю .gitignoreв эти каталоги файл со следующим содержимым:

*
!.gitignore

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