Чи нахмурилися кілька `.gitignore`?

Якщо РЕПО не складалося з декількох незалежних проектів, здається, було б найпростіше мати один .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правило ігнорує мій файл? "

Про сингл

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

• Положення правил виключення може бути досить важким, якщо в мене є кілька рейтингів на декількох рівнях репо.

• За допомогою декількох файлів ви, як правило, закінчуєтесь численним копіюванням.

Про кілька разів

• Охоплює "знання" до частини файлового дерева там, де це потрібно.

• Оскільки Git відстежує лише файли, порожній .gitignore - єдиний спосіб ввести "порожній" каталог.

  (А до Git 1.8 єдиний спосіб виключити такий зразок, як my/**.exampleце - створити my/.gitignoreз малюнком **.foo. Ця причина зараз не застосовується, як це можна зробити /my/**/*.example.)

Я дуже віддаю перевагу одному файлу, де я можу знайти всі виключення. Я ніколи не пропускав per-directory .svn, а також не пропускатиму per-directory .gitignore.

Однак, численні гітіньори є досить поширеними. Якщо ви все-таки використовуєте їх, принаймні будьте послідовними в їх використанні, щоб зробити їх розумними для роботи. Наприклад, ви можете розмістити їх у каталогах лише на одному рівні від кореня.

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

Тому я завжди роблю це додавати .gitignoreфайл у ці каталоги із наступним вмістом:

*
!.gitignore

З цим .gitignoreфайлом Git не буде відслідковувати жодних файлів у цих каталогах, але все ще дозволяє мені додати .gitignoreфайл і, отже, сам каталог до репо.