Применяется ли файл .gitignore ко всем веткам?

Question

Применяется ли файл .gitignore в ветке Master к другим ветвям?

В разделе «Создание локального .gitignore» в https://help.github.com/en/articles/ignoring-files, не указывается, в какой ветке вы должны находиться.

Answer 1

.gitignore применяется к файлам в папке , в которой находится файл .gitignore;не имеет значения, какую ветку вы выбрали в данный момент. Любые файлы, указанные в .gitignore, будут исключены из Git.

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

Answer 2

Разные ветки могут содержать разные .gitignore файлы, и каждый из них относится к веткам, в которых он появляется. Чтобы создать правила, применимые ко всем веткам, отредактируйте .git/info/exclude.

Документация gitignore охватывает несколько файлов, которые могут содержать шаблоны игнорирования.

Какой файлразмещение шаблона зависит от того, как этот шаблон предполагается использовать.

• Шаблоны, которые должны контролироваться версиями и распространяться в других репозиториях через клон (т. е. файлы, которые будут нужны всем разработчикам). игнорировать) следует перейти в файл .gitignore.

• Шаблоны, которые относятся к конкретному репозиторию, но которые не должны использоваться совместно с другими связанными репозиториями (например, вспомогательными файлами, которыедолжны находиться в репозитории, но относятся только к рабочему процессу одного пользователя) и должны входить в файл $GIT_DIR/info/exclude.

• Шаблоны, которые пользователь хочет игнорировать Git во всех ситуациях (например, резервное копирование или временное сохранение). файлы, сгенерированные выбранным редактором пользователя), обычно помещаются в файл, указанный в core.excludesFile в пользовательском ~/.gitconfig. Его значение по умолчанию $XDG_CONFIG_HOME/git/ignore. Если $XDG_CONFIG_HOME либо не задано, либо пусто, вместо него используется $HOME/.config/git/ignore.

Ваш вопрос о файле .gitignore в основной ветви и, таким образом, соответствуетпервый маркер.

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

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

Answer 3

Как сказал Возраст Обсидиана , он применяется к файлам в поддереве с корнем в той точке, в которой появляется файл .gitignore.

A .gitignore file должен отслеживаться ¹ (т. е. должен присутствовать в индексе) и, следовательно, существовать как копия в каждом коммите. Это означает, что каждый коммит имеет свою собственную .gitignore копию . ² Если вы находитесь на branch-1, а вы git checkout branch-2, и это выдает другую Файл .gitignore, его содержимое теперь применяются к папке и подпапкам. Если затем вы git checkout branch-1 вернете branch-1 файлы, включая branch-1 версию .gitignore, , то содержимое теперь применимо.

---

¹ Это не сложное требование, но не фиксация файла .gitignore означает, что вам, вероятно, вообще не следует использовать файл .gitignore. Вы можете получить аналогичный эффект, создав глобальный gitignore (для себя) или файл .git/info/excludes для этого одного хранилища.

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

То есть предположим, что вы git checkout master создаете файл размером 10 мегабайт с именем bigзапустите git add big, а затем git commit. Теперь вы создали новый файл размером 10 МБ, который находится в только что сделанном вами коммите. Каждый коммит, который вы делаете после этой точки, также содержит файл размером 10 МБ, вплоть до git rm big, чтобы удалить его из дерева индексов и работы и сделать все будущие коммиты неУ есть файл. ³ Но каждый файл, который разделяет точную версию большого файла, использует одну единственную общую копию. Поэтому, если у вас есть четыре тысячи коммитов, но все они имеют только один конкретный файл big, у вас есть только 10 МБ big, а не 4000 * 10 МБ.

³ Или, конечно, вы можете перезаписать big крошечным содержимым. Сделанный вами next коммит будет иметь небольшой файл с именем big, который будет использоваться совместно с каждым будущим коммитом, точно так же, как большой файл с именем big передается с каждым будущим коммитом до этого момента.

Если это слишком запутанно, просто представьте, что Git автоматически выполняет процедуру дедупликации «посмотрите, были ли эти данные когда-либо зафиксированы до», каждый раз, когда вы git add делаете файл. Если это действительно когда-либо было зафиксировано ранее, Git автоматически повторно использует уже замороженную копию.