Эта версия GitHub Enterprise Server была прекращена 2024-07-09. Исправления выпускаться не будут даже при критических проблемах безопасности. Для повышения производительности, повышения безопасности и новых функций выполните обновление до последней версии GitHub Enterprise Server. Чтобы получить справку по обновлению, обратитесь в службу поддержки GitHub Enterprise.

Использование REST API для взаимодействия с базой данных Git

Используйте REST API для чтения и записи необработанных объектов Git в базу данных Git на GitHub Enterprise Server и для перечисления и обновления ссылок (головки и теги ветвей).

В этой статье

Обзор

В основном это позволяет повторно использовать множество функциональных возможностей Git с помощью REST API, создавая необработанные объекты непосредственно в базу данных и обновляя ссылки на ветви, вы можете технически сделать практически все, что Git может сделать без установки Git.

REST API возвращает 409 Conflict значение, если репозиторий Git пуст или недоступен. Недоступный репозиторий обычно означает, что GitHub Enterprise Server находится в процессе создания репозитория. Для пустого репозитория можно использовать PUT /repos/{owner}/{repo}/contents/{path} конечную точку REST API для создания содержимого и инициализации репозитория, чтобы использовать API для управления базой данных Git. Если этот статус ответа сохраняется, вам поможет ваш администратор сайта.

Дополнительные сведения о базе данных объектов Git см. в главе Основы Git книги "Pro Git".

Например, если вы хотите зафиксировать изменение файла в репозитории, выполните следующие действия:

  • Получите текущий объект фиксации.
  • Извлеките дерево, на которое он указывает.
  • Извлеките содержимое BLOB-объекта этого дерева для конкретного пути к файлу.
  • Измените содержимое и опубликуйте новый BLOB-объект с новым содержимым, получив SHA BLOB-объекта.
  • Опубликуйте новый объект дерева, заменив указатель пути к файлу на SHA BLOB-объекта, чтобы получить SHA дерева.
  • Создайте объект фиксации с текущим SHA фиксации в качестве родительского и SHA нового дерева, получив SHA фиксации.
  • Обновите ссылку на ветвь, чтобы указать на новый SHA фиксации.

Это может показаться сложной процедурой, но на самом деле все довольно просто, если вы понимаете принцип. Использование API дает вам много возможностей.

Проверка возможности слияния запросов на вытягивание

Предупреждение. Не используйте Git напрямую или GET /repos/{owner}/{repo}/git/refs/{ref} для обновлений ссылок Git merge, так как это содержимое устаревает без предупреждения.

Потребляющий API должен явно запросить запрос на вытягивание для создания тестовой фиксации слияния. Тестовая фиксация слияния создается при просмотре запроса на вытягивание в пользовательском интерфейсе и отображении кнопки "Слияние" или при получении, создании или изменении запроса на вытягивание с помощью REST API. Без этого запроса ссылки Git merge будут устаревать до того, как кто-то просмотрит запрос на вытягивание.

Если вы используете методы опроса, которые создают устаревшие ссылки Git merge, GitHub рекомендует выполнить следующие действия, чтобы получить последние изменения из ветви по умолчанию:

  1. Получите веб-перехватчик запроса на вытягивание.
  2. Вызовите GET /repos/{owner}/{repo}/pulls/{pull_number}, чтобы запустить фоновое задание для создания кандидата на фиксацию слияния.
  3. Опросите репозиторий, используя GET /repos/{owner}/{repo}/pulls/{pull_number}, чтобы узнать, является ли атрибут mergeable true или false. Вы можете использовать Git напрямую или GET /repos/{owner}/{repo}/git/refs/{ref} для обновления только ссылок Git merge после выполнения предыдущих шагов.