Когда диспетчер пакетов извлекает пакет из репозитория Git, он добавляет пакет локально в ваш проект. Это позволяет вам легко тестировать неопубликованные изменения, но вы не можете использовать его для внесения вклада в этот репозиторий Git. Чтобы настроить существующий локальный репозиторий Git в качестве зависимости
См. Словарь в вашем проекте, используйте вместо этого путь к вашему локальному репозиторию Git.
Вы не можете указать зависимости GitДиспетчер пакетов получает зависимости Git напрямую из репозитория Git, а не из реестра пакетов. Зависимости Git используют ссылку URL-адреса Git вместо версии, и нет никаких гарантий относительно качества, стабильности, достоверности пакета или даже того, соответствует ли версия, указанная в его файле package.json. Правила семантического управления версиями в отношении официально опубликованных выпусков этого пакета. Дополнительная информация
См. в Словарь в пакете .json, поскольку диспетчер пакетов не поддерживает зависимости Git между пакетами. Он поддерживает только зависимости Git для проектов, поэтому вы можете объявлять зависимости Git только в файле manifest.json проекта.
Совет. Если вы хотите обновить свою зависимость Git до определенной версии (редакция) из репозитория, см. Заблокированные зависимости Git.
Этот раздел включает следующие темы:
Требования
Чтобы использовать зависимости Git в проекте, убедитесь, что клиент Git (минимальная версия 2.14.0) установлен на вашем компьютере и что вы добавили путь к исполняемому файлу Git в переменную системной среды PATH.
Предупреждение. Менеджер пакетов был протестирован на совместимость с Git 2.14.0 и выше. Unity не может гарантировать результаты, если вы используете версии Git ниже 2.14.0.
Если репозиторий отслеживает файлы с помощью Git LFS, убедитесь, что клиент Git LFS также установлен на твоя машина. Если он не установлен, диспетчер пакетов не может получить файлы, хранящиеся на сервере LFS, и вместо этого извлекает файлы указателей LFS без каких-либо ошибок или ошибок. предупреждающие сообщения.
Вы можете использовать окно диспетчера пакетов для установки пакета непосредственно из репозитория Git. Дополнительную информацию см. в разделе Установка с URL-адреса Git.
URL-адреса Git и расширенный синтаксис
Диспетчер пакетов поддерживает все Git-протоколы, за исключением прямых путей к файлам. Чтобы указать URL-адрес Git в качестве зависимости, добавьте имя пакета для добавления с помощью URL-адреса Git вместо номера версии или пути к локальному файлу. Например, это демонстрирует, как указать удаленный Git, используя разные протоколы:
{
"dependencies": {
"com.mycompany.mypackage1": "https://github.example.com/myuser/myrepository1.git",
"com.mycompany.mypackage2": "ssh://git@github.example.com/myuser/myrepository2.git",
"com.mycompany.mypackage3": "file://localhost/github.example.com/myuser/myrepository3.git",
"com.mycompany.mypackage4": "git://github.example.com/myuser/myrepository4.git",
etc.
}
}
Диспетчер пакетов распознает, что зависимость, отформатированная как URL-адрес, является URL-адресом Git, ища расширение файла .git в конце пути к репозиторию. Некоторые службы размещения репозиториев Git не поддерживают URL-адреса с этим расширением, в то время как другие используют его принудительно. По этой причине синтаксис зависимостей Git позволяет опустить расширение, если вы используете протокол GIT или добавляете специальный git+ префикс для HTTP/HTTPS, SSH или ФАЙЛ URL-адрес.
Примечание. Префикс git+ — это специальный маркер в файле manifest.json, который указывает, что зависимость основана на Git. Управление пакетами не передает его в Git при клонировании репозитория.
Дополнительную информацию о формате URL-адресов, поддерживаемых Git, см. в документации по git . команду клонировать. Обзор различий между протоколами, которые использует Git, см. в разделе документация Git по использованию протоколов.
Кроме того, зависимости Git используют расширенный синтаксис:
-
Если нужный пакет находится не в корне репозитория, вы можете указать путь к подпапке в репозитории, где находится пакет. Это необходимо только в том случае, если нужный пакет находится не в корне репозитория. Например, строка
?path=/folder1/folder2в:"https://github.example.com/myuser/myrepository.git?path=/folder1/folder2".Дополнительную информацию см. в разделе Указание пакета во вложенной папке.
-
Вы можете указать версию Git, которая может быть тегом, именем ветки или конкретным хэшем коммита для блокировки. Это гарантирует, что диспетчер пакетов всегда загружает именно эту версию. Если вы не укажете ревизию, диспетчер пакетов клонирует репозиторий в ветке по умолчанию и последней фиксации. Например, строка
#v2.0.0в:"https://github.example.com/myuser/myrepository.git#v2.0.0"Дополнительную информацию см. в разделе Нацеливание на конкретную версию.
Использование протокола HTTP/HTTPS
Вы можете использовать протокол HTTPS с полным URL-адресом:
{
"dependencies": {
"com.mycompany.mypackage": "https://github.example.com/myuser/myrepository.git"
}
}
Если ваш сервер Git не поддерживает расширение .git, вы можете добавить специальный префикс git+ с префиксом или без него. расширение:
{
"dependencies": {
"com.mycompany.mypackage1": "git+https://github.example.com/myuser/myrepository1.git",
"com.mycompany.mypackage2": "git+https://github.example.com/myuser/myrepository2"
}
}
Примечание. В качестве альтернативы вы можете использовать протокол GIT вместо префикса git+. Дополнительную информацию см. в разделе Использование протокола GIT.
Если репозиторий общедоступен, HTTPS является рекомендуемой схемой для обмена URL-адресами Git с пользователями, поскольку вы можете скопировать и вставить URL-адрес непосредственно с веб-страницы службы размещения репозитория Git.
Если репозиторий недоступен публично и вы используете HTTPS, серверу репозитория не удастся аутентифицировать вас, поскольку вы не можете взаимодействовать с сервером для предоставления своих учетных данных. В этом случае редактор уведомит вас о том, что аутентификация не удалась.
Чтобы обойти эти проблемы с аутентификацией, вы можете либо пройти аутентификацию заранее, используя помощник по учетным данным Git, либо вместо этого используйте протокол SSH. Если вы установили и настроили пару ключей SSH со службой размещения репозитория Git, диспетчер пакетов может беспрепятственно аутентифицировать запрос от вашего имени.
Использование протокола SSH
Вы можете использовать протокол SSH с полным URL-адресом:
{
"dependencies": {
"com.mycompany.mypackage": "ssh://git@mycompany.github.com/gitproject/com.mycompany.mypackage.git"
}
}
Если ваш сервер Git не поддерживает расширение .git, вы можете добавить специальный префикс git+ с префиксом или без него. расширение:
{
"dependencies": {
"com.mycompany.mypackage1": "git+ssh://git@github.example.com/myuser/myrepository1.git",
"com.mycompany.mypackage2": "git+ssh://git@github.example.com/myuser/myrepository2"
}
}
Примечание. В качестве альтернативы вы можете использовать протокол GIT вместо префикса git+. Дополнительную информацию см. в разделе Использование протокола GIT.
Вы также можете использовать сокращение, похожее на SCP, которое диспетчер пакетов всегда распознает как зависимость от Git:
{
"dependencies": {
"com.mycompany.mypackage": "git@mycompany.github.com:gitproject/com.mycompany.mypackage.git"
}
}
Использование PuTTY в Windows
Git использует ключи в расположении по умолчанию, когда вы используете SSH для аутентификации. Однако если вы используете PuTTY в качестве клиента SSH в Windows, вам необходимо настроить GIT_SSH, чтобы она указывала на plink.exe.
Аутентификация с помощью SSH
Если вы хотите использовать протокол SSH, вам необходимо настроить ключи SSH вне Unity. Дополнительные сведения о настройке аутентификации для определенного хоста см. на страницах справки для Bitbucket, GitLab и GitHub.
Примечание. Если вы зашифровали ключ SSH с помощью парольной фразы, диспетчер пакетов не сможет получить пакет, поскольку он не позволяет ввести парольную фразу в терминале или в командной строке. . В этом случае Редактор уведомляет вас о том, что аутентификация не удалась. Справку по использованию ssh-agent для аутентификации см. в разделе Решения для SSH.
Использование протокола FILE
Диспетчер пакетов не распознает URL-адреса Git с префиксом file: как зависимости Git, если они не отформатированы должным образом. Это означает, что вы должны использовать либо протокол git+file:, либо суффикс .git с file: протокол:
{
"dependencies": {
"com.mycompany.mypackage1": "git+file://github.example.com/myuser/myrepository1",
"com.mycompany.mypackage2": "git+file:///github.example.com/myuser/myrepository2",
"com.mycompany.mypackage3": "file:///github.example.com/myuser/myrepository3.git"
}
}
Примечание. В качестве альтернативы вы можете использовать протокол GIT вместо префикса git+. Дополнительную информацию см. в разделе Использование протокола GIT.
Диспетчер пакетов интерпретирует любой другой синтаксис как локальный путь.
Использование протокола GIT
Диспетчер пакетов распознает протокол git: с суффиксом пути .git или без него:
{
"dependencies": {
"com.mycompany.mypackage1": "git://github.example.com/myuser/myrepository1.git",
"com.mycompany.mypackage2": "git://github.example.com/myuser/myrepository2"
}
}
Протокол GIT не требует и не поддерживает префикс git+.
Таргетинг на конкретную версию
Чтобы объявить конкретную версию, которую вы хотите клонировать с помощью диспетчера пакетов, добавьте номер версии с префиксом (#) в конце URL-адреса:
{
"dependencies": {
"com.mycompany.mypackage1": "https://github.example.com/myuser/myrepository1.git#revision",
"com.mycompany.mypackage2": "git+https://github.example.com/myuser/myrepository2#revision"
}
}
Ревизия может быть любым тегом, веткой или хэшем коммита. Вы должны предоставить полный хэш коммита. Unity не поддерживает укороченные хэши SHA-1. В этой таблице показаны примеры указания редакций:
| Синтаксис: | URL пример |
|---|---|
| Latest default branch | "https://github.example.com/myuser/myrepository.git" |
| Specific branch | "https://github.example.com/myuser/myrepository.git#my-branch" |
| Specific version | "https://github.example.com/myuser/myrepository.git#v2.0.0" |
| Commit hash | "https://github.example.com/myuser/myrepository.git#9e72f9d5a6a3dadc38d813d8399e1b0e86781a49" |
Указание пакета во вложенной папке репозитория
Если вы указываете репозиторий с использованием синтаксиса Git URL, диспетчер пакетов предполагает, что пакет должен находиться в корне репозитория. Однако некоторые пакеты не расположены на корневом уровне своего репозитория, а некоторые репозитории содержат более одного пакета.
Вы можете использовать параметр запроса path в URL-адресе Git, чтобы уведомить диспетчер пакетов, где найти пакет. Указанный вами путь должен относиться к корню репозитория, а указанная подпапка должна содержать манифест пакетаКаждый пакет имеет манифест, который предоставляет информацию о пакете диспетчеру пакетов. Манифест содержит такую информацию, как имя пакета, его версия, описание для пользователей, зависимости от других пакетов (если есть) и другие подробности. Дополнительная информация
См. в Словарь (package.json файл).
Чтобы указать подпапку репозитория для зависимости Git, используйте параметр запроса path:
{
"dependencies": {
"com.mycompany.mypackage": "https://github.example.com/myuser/myrepository.git?path=/subfolder"
}
}
В этом случае диспетчер пакетов регистрирует только пакет, расположенный в указанной подпапке репозитория, и игнорирует остальную часть репозитория.
Иногда репозиторий содержит несколько связанных пакетов. Если вы хотите добавить более одного пакета из одного и того же репозитория, вы должны добавить две отдельные записи в свой манифест проектакаждого проекта Unity. имеет манифест проекта, который действует как точка входа для диспетчера пакетов. Этот файл должен находиться в каталоге
См. в Словарь:
{
"dependencies": {
"com.mycompany.mypackage1": "https://github.example.com/myuser/myrepository.git?path=/subfolder1",
"com.mycompany.mypackage3": "https://github.example.com/myuser/myrepository.git?path=/subfolder2/subfolder3"
}
}
Примечание. Если вы укажете один и тот же репозиторий несколько раз, диспетчер пакетов будет клонировать один и тот же репозиторий несколько раз, что приведет к снижению производительности и увеличению нагрузки на сеть.
Одновременное использование путей и ревизий
Параметр запроса path всегда предшествует привязке редакции. Обратный порядок не работает. Это пример правильного порядка использования:
{
"dependencies": {
"com.mycompany.mypackage": "https://github.example.com/myuser/myrepository.git?path=/example/folder#v1.2.3"
}
}
Заблокированные зависимости Git
Одним из основных принципов диспетчера пакетов является детерминизм. Если вы делитесь своим проектом с другими пользователями, диспетчер пакетов должен установить тот же набор зависимостей и версий пакетов, включая пакеты, которые он получает из Git. Для этого диспетчер пакетов использует файл блокировки, который отслеживает, какие хэши коммитов используются для зависимостей Git.
Когда вы добавляете зависимость Git с набором ревизий для ветки или тега, диспетчер пакетов извлекает соответствующий хэш фиксации для сохранения в файле блокировки. Со временем ветки и теги могут указывать на разные коммиты в репозитории Git. Например, в ветку могут быть добавлены новые коммиты.
Чтобы обновить пакет до другой фиксации, на которую указывает ветвь или тег, используйте кнопку Добавить пакет из URL-адреса git и введите URL-адрес Git. Вы можете использовать тот же URL-адрес Git, поскольку диспетчер пакетов игнорирует заблокированный хэш фиксации при отправке нового запроса. Вы также можете указать новый номер редакции, тег или ветвь в качестве редакции.
Кроме того, вы можете создать сценарий с помощью метода C# Client.Add API с этим URL-адресом Git.
Поддержка Git LFS
Диспетчер пакетов поддерживает зависимости Git от репозиториев с помощью Git LFS. Поскольку Git LFS был разработан для работы с минимальными затратами на настройку, он поддерживает как HTTPS, так и SSH аутентификацию. Извлечение файлов, хранящихся на сервере LFS, завершается ошибкой, если пользователи должны пройти аутентификацию и не имеют действительных учетных данных с разрешением на доступ к удаленному репозиторию.
Авторы пакетов могут помочь клиенту Git LFS найти сервер LFS, предоставив ему URL-адрес в файле конфигурации .lfsconfig в репозитории. Это можно сделать двумя способами:
# Option 1: global setting
[lfs]
url = ssh://git@HOSTNAME/path/to/repo.git
# Option 2: per-remote setting
[remote "origin"]
lfsurl = ssh://git@HOSTNAME/path/to/repo.git
Если репозиторий содержит файл .lfsconfig, убедитесь, что вы включили его в файл .npmignore, чтобы избежать его включения в опубликованных версиях пакета.
Кэш Git LFS
По умолчанию клиент Git LFS кэширует файлы, загруженные с сервера LFS, в папку .git/lfs вашего репозитория Git. Это позволяет избежать загрузки одного и того же файла каждый раз, когда вы проверяете другую версию репозитория. Однако диспетчер пакетов не может использовать этот кеш для зависимостей Git, поскольку он не сохраняет клонированные репозитории после того, как пакеты были скопированы в кеш проекта.
Начиная с Unity 2021.2, вы можете дополнительно включить кеш Git LFS, чтобы диспетчер пакетов использовал его при проверке зависимостей на основе Git.
Для этого выберите один из следующих вариантов:
- Чтобы включить кэш Git LFS и использовать подпапку
git-lfsв корневом каталоге глобального кэша по умолчанию в качестве его место, задайте для переменной средыUPM_ENABLE_GIT_LFS_CACHEлюбое (непустое) значение. - Чтобы включить кеш Git LFS и использовать для него настраиваемое расположение, задайте для переменной среды
UPM_GIT_LFS_CACHE_PATHнастраиваемый путь. Когда вы задаете местоположение, параметр кэша Git LFS включается автоматически.
Дополнительную информацию о том, как задать переменные среды для глобального кеша, см. в разделе Настройка мест общего кеша.
Примечание. Для этой оптимизации требуется дополнительное место на диске при использовании пакетов Git с поддержкой LFS. Вам нужно решить, что является большим преимуществом: кэширование файлов Git LFS требует дискового пространства, но позволяет сэкономить на повторной загрузке тех же файлов. Однако в некоторых ситуациях невозможно использовать кеш и использовать дисковое пространство без повторного использования файлов. Например, ваши зависимости Git могут разрешаться в ревизии, которые ссылаются на другое содержимое файла, отслеживаемое LFS, например в следующих сценариях:
- Использование разных версий Git в зависимостях в нескольких проектах
- Частое обновление пакета до версий, содержащих другие измененные файлы LFS