Когда использовать ведущий слеш в gitignore

Question

Я пытаюсь понять более четко .gitignore синтаксис, и в частности, что касается https://github.com/github/gitignore gitignores.

Я вижу, что начальная косая черта используется для сопоставления только имен путей относительно местоположения .gitignore файл (из http://git-scm.com/docs/gitignore):

Начальная косая черта соответствует началу пути. Например, "/*.c" соответствует "cat-file.c", но не "mozilla-sha1/sha1.c".

Но что происходит, когда я удаляю косую черту? Насколько я понял, есть два случая:

1. Если шаблон не содержит косую черту (или содержит только косую черту, что означает, что он должен соответствовать каталогу), поиск выполняется внутри всего дерева каталогов. Например, шаблон dir/ будет соответствовать <root>/dir, <root>/a/dir, <root>/a/b/c/.../dirи т. д., где <root> это местоположение .gitignore файл.
2. Если шаблон содержит косую черту, которая не находится в конечной позиции (это не последний символ), то он сопоставляется только с путевыми именами относительно .gitignore расположение файла.

Вот примеры, которые я сделал, чтобы проверить это поведение:

# Directory structure:
<root>
|- dir/
|   |- test
|- src/
|   |- dir/
|   |   |- test
test file is there only because Git does not track empty directories.

Первый тест:

# .gitignore
dir/

# git status
nothing to commit

Так что Git игнорирует оба dir каталоги. Это согласуется со случаем № 1: в шаблоне нет косых черт (кроме завершающего), поэтому Git просматривает все дерево каталогов, игнорируя все, что соответствует шаблону.

Второй тест:

# .gitignore
/dir/

# git status
Untracked files:
    src/

Здесь Git игнорирует только dir каталог непосредственно под корневым каталогом, благодаря косой черте в шаблоне.

Третий тест:

# .gitignore
dir/*

# git status
Untracked files:
    src/

Это согласуется со случаем № 2: шаблон имеет косую черту, поэтому он считается именем пути, начинающимся с корневого каталога.

Теперь пришло время для реального вопроса. Давайте рассмотрим этот файл gitignore: когда они игнорируют каталог downloader/Например, разве они не игнорируют каждый downloader каталог найден во всем дереве каталогов? Это то, о чем я думаю, начиная с того, что я видел о работе Git раньше.

Так что, если у меня есть пользовательский модуль с downloader каталог внутри него, будет ли он неожиданно проигнорирован так же, как обычный каталог в корне Magento? Это немного риторический вопрос, потому что это на самом деле уже случилось со мной, создавая действительно трудно найти ошибку.

Итак, в Magento .gitignore Файл (который я имею в виду только в качестве примера, кстати), многие шаблоны содержат косые черты, поэтому они правильно сопоставляются с путями, начиная с корня, но есть несколько случаев, например downloader/ или же errors/ что, если я не ошибаюсь, они потенциально опасны, и которые, вероятно, следует изменить на /downloader/ а также /errors/,

В качестве более общего вопроса, должен ли я всегда использовать начальную косую черту для шаблонов, не содержащих косые черты (кроме завершающей), когда я хочу выбрать путь, явно начинающийся с root, и не использовать его для шаблонов, содержащих косые черты, или всегда использовать ведущий слеш для ясности? Что вы думаете об этом?

Спасибо за чтение и простите за длинный пост.

Answer 1

Просто хотел подвести итог для возможного быстрого будущего обращения - ведущий слэш закрепляет совпадение с корнем. Таким образом, в приведенном ниже примере без косой черты подстановочный знак также будет исключать все в foo, потому что это займет * и двигаться рекурсивно вниз по дереву. Однако с /*, он исключает все, кроме папки foo и ее содержимого:

$ cat .gitignore
/*
!/foo

Answer 2

Вы полностью ответили на свой вопрос. Если вы посмотрите на репозиторий github/gitignore более внимательно, вы увидите, что большинство файлов используют противоречивые правила написания шаблонов; скорее всего, большинство из них были сделаны людьми, которые не удосужились ни прочитать документацию, ни протестировать, как вы.

Так что, если это поможет: ты прав, будь уверен.

Если вы видите ошибки в таких совместных проектах, не стесняйтесь делиться своими знаниями. Есть даже какой-то прецедент, если вам нужно еще больше укрепить свою уверенность.