Ошибки клонирования HTTPS
При использовании HTTPS с GIT распространен ряд ошибок. Обычно они указывают на то, что у вас старая версия GIT или нет доступа к репозиторию.
Ниже приведен пример возможной ошибки HTTPS:
> error: The requested URL returned error: 401 while accessing
> https://HOSTNAME/USER/REPO.git/info/refs?service=git-receive-pack
> fatal: HTTP request failed
> Error: The requested URL returned error: 403 while accessing
> https://HOSTNAME/USER/REPO.git/info/refs
> fatal: HTTP request failed
> Error: https://HOSTNAME/USER/REPO.git/info/refs not found: did you run git
> update-server-info on the server?
Проверка версии GIT
Ограничений на минимальную версию GIT, требуемую для взаимодействия с GitHub Enterprise Server, нет, но, по нашему опыту, версия 1.7.10 является удобной, стабильной версией, доступной на многих платформах. Последнюю версию всегда можно скачать на веб-сайте GIT.
Проверка правильности удаленного репозитория
Репозиторий, который вы пытаетесь получить, должен существовать в экземпляр GitHub Enterprise Server, а URL-адрес учитывает регистр.
Чтобы узнать URL-адрес локального репозитория, можно открыть командную строку и ввести git remote -v
:
$ git remote -v
# View existing remotes
> origin https://github.com/ghost/reactivecocoa.git (fetch)
> origin https://github.com/ghost/reactivecocoa.git (push)
$ git remote set-url origin https://github.com/ghost/ReactiveCocoa.git
# Change the 'origin' remote's URL
$ git remote -v
# Verify new remote URL
> origin https://github.com/ghost/ReactiveCocoa.git (fetch)
> origin https://github.com/ghost/ReactiveCocoa.git (push)
Кроме того, можно изменить URL-адрес с помощью приложения GitHub Desktop.
Предоставление маркера доступа
Чтобы получить доступ к GitHub, необходимо пройти проверку подлинности с помощью personal access token вместо пароля. Дополнительные сведения см. в разделе Создание личного маркера доступа.
Проверить свои разрешения
При появлении запроса на ввод имени пользователя и пароля используйте учетную запись с доступом к репозиторию.
Совет. Если вы не хотите вводить учетные данные при каждом взаимодействии с удаленным репозиторием, можно включить кэширование учетных данных. Если кэширование учетных данных уже используется, убедитесь в том, что на компьютере кэшированы правильные учетные данные. Неправильные или устаревшие учетные данные не позволят пройти проверку подлинности.
Использование SSH
Если вы ранее настроили ключи SSH, можно использовать URL-адрес клонирования SSH вместо HTTPS. Дополнительные сведения см. в разделе Сведения об удаленных репозиториях.
Ошибка: репозиторий не найден
Если эта ошибка возникает при клонировании репозитория, это означает, что репозиторий не существует, у вас нет разрешения на доступ к нему или экземпляр GitHub Enterprise Server находится в частном режиме. Существует несколько решений для этой ошибки в зависимости от причины.
Проверка правильности написания
Всегда есть вероятность опечатки. Кроме того, в именах репозиториев учитывается регистр символов. Если вы попытаетесь клонировать git@HOSTNAME:user/repo.git
, но репозиторий на самом деле называется User/Repo
, произойдет эта ошибка.
Чтобы избежать этой ошибки, при клонировании всегда копируйте URL-адрес клона со страницы репозитория, а затем вставляйте его. Дополнительные сведения см. в разделе Клонирование репозитория.
Сведения об обновлении удаленного репозитория см. в разделе Управление удаленными репозиториями.
Проверка разрешений
Если вы пытаетесь клонировать частный репозиторий, но не имеете разрешения на его просмотр, произойдет эта ошибка.
Убедитесь в том, что у вас есть один из следующих уровней доступа:
- владелец репозитория;
- участник совместной работы над репозиторием;
- участник команды, которая имеет доступ к репозиторию (если репозиторий принадлежит организации).
Проверка доступа по протоколу SSH
В редких случаях может отсутствовать доступ к репозиторию по протоколу SSH из-за неправильной настройки.
Убедитесь в том, что используемый ключ SSH связан с личной учетной записью на GitHub Enterprise Server. Это можно проверить, введя в командную строку следующую команду:
$ ssh -T git@HOSTNAME
> Hi USERNAME! You've successfully authenticated, but GitHub does not
> provide shell access.
Дополнительные сведения см. в разделе Добавление нового ключа SSH в учетную запись GitHub.
Проверка режима, в котором находится экземпляр
Если администратор сайта включил частный режим в экземпляре GitHub Enterprise, анонимные клоны по git://
будут отключены. Если вам не удается клонировать репозиторий, обратитесь к администратору сайта.
Проверка существования репозитория
Если все остальное не удается, убедитесь, что репозиторий действительно существует в экземпляр GitHub Enterprise Server! Если вы пытаетесь выполнить отправку в несуществующий репозиторий, произойдет эта ошибка.
Ошибка: файл HEAD удаленного репозитория ссылается на несуществующую ветвь; не удалось выполнить извлечение
Эта ошибка возникает, если ветвь репозитория по умолчанию была удалена в экземпляр GitHub Enterprise Server.
Обнаружить эту ошибку легко: GIT предупредит вас при попытке клонировать репозиторий:
$ git clone https://HOSTNAME/USER/REPO.git
# Clone a repo
> Cloning into 'repo'...
> remote: Counting objects: 66179, done.
> remote: Compressing objects: 100% (15587/15587), done.
> remote: Total 66179 (delta 46985), reused 65596 (delta 46402)
> Receiving objects: 100% (66179/66179), 51.66 MiB | 667 KiB/s, done.
> Resolving deltas: 100% (46985/46985), done.
> warning: remote HEAD refers to nonexistent ref, unable to checkout.
Чтобы устранить эту ошибку, необходимо быть администратором репозитория в экземпляр GitHub Enterprise Server. Вам потребуется изменить ветвь по умолчанию репозитория.
После этого можно получить список всех доступных ветвей из командной строки:
$ git branch -a
# Lists ALL the branches
> remotes/origin/awesome
> remotes/origin/more-work
> remotes/origin/new-main
Затем можно просто переключиться на новую ветвь:
$ git checkout new-main
# Create and checkout a tracking branch
> Branch new-main set up to track remote branch new-main from origin.
> Switched to a new branch 'new-main'