Перейти к содержимому

Проверить и смержить PR

В этом руководстве показано, как проверить и смержить pull request.

  1. Перейдите в Pull requests на боковой панели
  2. Выберите PR из списка

PR открывается как верстак с вкладками, а не как отдельная страница. По умолчанию открыты пять вкладок, в таком порядке: Обзор, Различия, Контроль версий, Чат и Действия (проверки CI, сгруппированные по workflow). Ревью — ход конвейера проверки, а затем опубликованный им артефакт с панелью замечаний — намеренно в их число не входит: у PR нет проверки, пока её кто-нибудь не запросит, поэтому её открывает Спросить AI. Терминал, редактор одного файла, встроенный code-server и браузер внутри приложения открываются по запросу; вкладки предпросмотра развёртывания добавляются автоматически, когда в PR обнаруживается URL предпросмотра. Раскладка вкладок запоминается для каждого PR.

Вкладка «Обзор» содержит метаданные PR (автор, ветка, метки, исполнители, реакции, коммиты, состояние проверок) и строку действий: обновить, Ревью, Слить, открыть в IDE и меню переполнения ⋯.

Откройте вкладку Различия, чтобы увидеть весь diff PR сразу, с деревом файлов для перехода между файлами.

  • Кнопка настроек на панели инструментов diff переключает разделённый (бок о бок) и объединённый вид, а также включает перенос строк и лигатуры шрифта кода.
  • Вместо заголовков блоков @@ появляются элементы Show N lines / Show end of file, которые по нажатию подставляют окружающий контекст.
  • Нажимайте j / k для перехода между файлами, c — чтобы свернуть или развернуть файл в фокусе, t — чтобы вернуть боковую панель к дереву файлов, и ⌘F — чтобы искать по всему diff (Enter / Shift+Enter перебирают совпадения).
  • Нажмите v, чтобы отметить файл в фокусе как просмотренный, — курсор перейдёт к следующему файлу. На GitHub состояние «просмотрено» хранится на хосте кода, поэтому оно следует за вами между клиентами; в GitLab и Bitbucket такого API нет, поэтому там оно запоминается только на этом устройстве.

Перетаскивание мышью в области кода выделяет текст вплоть до точного столбца, а ⌘C копирует исходный код, а не отрисованные маркеры diff.

  1. Нажмите на жёлоб строки кода, чтобы открыть форму комментария, привязанную к этой строке, или используйте кнопку + в заголовке файла для комментария ко всему файлу
  2. Напишите свой отзыв в формате Markdown
  3. Отправьте

На GitHub и GitLab форма предлагает две отправки: Добавить один комментарий публикует сразу, а Начать ревью / Добавить в ревью ставит комментарий в очередь отложенного ревью, которое уходит вместе с Одобрить, Запросить изменения или Комментировать. В Bitbucket пакетных ревью нет, поэтому там каждая отправка публикуется сразу. Немедленная публикация показывает состояние ожидания, пока хост кода её не подтвердит, после чего переключается на «синхронизировано». Если публикация не удалась, ветка помечается ошибкой и предлагает повторить.

Черновиком является только тело ревью: через мгновение после того, как вы перестанете печатать, оно сохраняется на сервере по ключу (owner, repo, номер PR), поэтому переживает перезагрузку и следует за вами между клиентами для компьютера и веб-клиентами.

  1. Нажмите Ревью в строке действий вкладки «Обзор» (для ваших собственных PR, а также для закрытого или слитого PR она скрыта)
  2. Напишите тело ревью. Можно прикрепить изображение, вставить эмодзи или GIF и переключаться между написанием и предпросмотром
  3. Нажмите Запросить изменения, Комментировать или Одобрить

Вердикт и есть кнопка — отдельного выбора вердикта нет. После Одобрить или Запросить изменения кнопка переименовывается в Одобрено или Запрошены изменения, а черновик тела очищается. Вердикт Комментарий оставляет на кнопке подпись Ревью.

Кнопка Слить появляется, когда у вас есть право на запись, а PR открыт и не является черновиком. Её цвет — сигнал готовности, вычисляемый по требуемым одобрениям и состоянию проверок (готово / в ожидании / заблокировано); он носит только рекомендательный характер. Состояние ревью никогда не отключает кнопку: правила обеспечивает собственная защита ветки на хосте кода.

  1. Нажмите Слить, чтобы открыть панель слияния
  2. Выберите способ слияния: squash, merge commit или rebase (по умолчанию — squash). В Bitbucket нет настоящего слияния через rebase, поэтому rebase сводится к его стратегии fast-forward и завершается ошибкой на разошедшейся ветке
  3. Для squash и merge commit отредактируйте предзаполненные заголовок и описание коммита. Rebase не принимает ни то, ни другое и скрывает оба поля
  4. Прочитайте панель предупреждений — в ней перечислены падающие проверки и ожидающие ревью, но она вас не блокирует
  5. Нажмите кнопку слияния на панели, чтобы подтвердить

Слияние необратимо: оно отправляет коммиты на хост кода, поэтому вместо записи в стеке отмены получает шаг подтверждения. После него кэш PR сбрасывается, его статус меняется на Слито, и срабатывает событие PullRequestStatusChanged со статусом merged. Это событие освобождает эфемерный worktree «открыть в редакторе» и запускает два предустановленных конвейера: Stale repository cleanup, который удаляет устаревшие worktrees и папки разговоров этого PR, и Release notes, который готовит черновик записи в списке изменений.

Меню переполнения ⋯ на вкладке «Обзор» содержит пункт Спросить AI, который запускает предустановленный конвейер pr_review для этого PR. Он появляется, только пока PR открыт. О том, что делает конвейер и как опубликовать его замечания, см. Использовать ИИ-проверку, а о детерминированной модели когорт и осей — Вычисления проверки.

Control Center также импортирует PR, открытые людьми вне приложения. Порядок проверки, описанный выше, тот же. Внешние PR обнаруживает служба опроса PR.