GitRiver GitRiver
EN
Навигация

Пулл-реквесты

Создание, ревью кода, стратегии слияния, очередь слияния и CODEOWNERS в GitRiver

Пулл-реквесты (Pull Requests, PR) - основной способ предложить изменения в код. Автор создаёт ветку, вносит изменения, открывает PR - ревьюеры проверяют код, оставляют комментарии, после одобрения PR сливается в целевую ветку.

Создание пулл-реквеста

Из командной строки

# Создать ветку и внести изменения
git checkout -b feature/new-api
# ... редактирование файлов ...
git add .
git commit -m "Добавлен новый API endpoint"
git push origin feature/new-api

После push в интерфейсе появится предложение создать PR.

Из интерфейса

  1. Нажмите «Новый пулл-реквест» в репозитории
  2. Выберите исходную ветку (с изменениями) и целевую ветку (куда сливать, обычно main)
  3. Заполните:
    • Заголовок - краткое описание изменений
    • Описание - подробности, мотивация, скриншоты (Markdown)
    • Ревьюеры - кто будет проверять код
    • Метки - категоризация
    • Веха - к какому релизу относится
  4. Нажмите «Создать»

Пулл-реквесты из форков

Внешние контрибьюторы могут форкнуть репозиторий и создать PR из форка:

  1. Форкните репозиторий (кнопка «Форк»)
  2. Внесите изменения в своём форке
  3. Нажмите «Новый пулл-реквест» - GitRiver автоматически определит целевой репозиторий

Черновик

Если PR ещё не готов к ревью - создайте его как черновик. Черновик нельзя слить, но ревьюеры могут оставлять комментарии. Когда готово - нажмите «Готов к ревью».

Ревью кода

Просмотр изменений

Вкладка «Изменения» (Changes) показывает diff всех файлов. Режимы:

  • Unified - изменения в одном столбце
  • Split - старый и новый код рядом

Построчные комментарии

  1. Наведите на строку в diff
  2. Нажмите «+» слева от строки
  3. Напишите комментарий (Markdown)
  4. Нажмите «Добавить комментарий» (отдельный) или «Начать ревью» (пакетный)

Пакетное ревью

Вместо отправки комментариев по одному:

  1. Нажмите «Начать ревью» на первом комментарии
  2. Оставьте все комментарии к разным файлам
  3. Нажмите «Завершить ревью» и выберите итог:
    • Одобрить (Approve) - код готов к слиянию
    • Запросить изменения (Request Changes) - нужны доработки
    • Комментарий (Comment) - без итога, просто заметки

Треды комментариев

Каждый построчный комментарий создаёт тред (обсуждение):

  • Автор PR отвечает на замечания
  • Ревьюер помечает тред как решённый (Resolved)
  • Нерешённые треды видны в сводке PR

CODEOWNERS

Файл CODEOWNERS в корне репозитория автоматически назначает ревьюеров по путям файлов.

# .gitriver/CODEOWNERS

# Backend
/src/api/          @backend-team
/src/database/     @dba-team @backend-team

# Frontend
/src/web/          @frontend-team
*.tsx              @frontend-team

# DevOps
/deploy/           @devops
Dockerfile*        @devops
.gitriver/ci.yml   @devops

# Документация - любой из команды
/docs/             @docs-team

Правила:

  • Последнее совпадение имеет приоритет
  • @username - конкретный пользователь
  • @group/team - команда в группе
  • Если PR затрагивает файл с CODEOWNER - ревьюер назначается автоматически
  • В защите веток можно потребовать одобрение от CODEOWNER

Стратегии слияния

При нажатии «Слить» доступны три стратегии:

Merge commit

* Merge pull request #42 (merge commit)
|\
| * Добавлен новый API endpoint
| * Исправлена валидация
|/
* Предыдущий коммит
  • Создаёт merge-коммит
  • Полностью сохраняет историю ветки
  • Легко откатить весь PR (revert merge commit)

Squash and merge

* Добавлен новый API endpoint (#42)
* Предыдущий коммит
  • Объединяет все коммиты PR в один
  • Чистая линейная история
  • Промежуточные коммиты (“fix typo”, “wip”) не засоряют историю

Rebase and merge

* Исправлена валидация
* Добавлен новый API endpoint
* Предыдущий коммит
  • Перебазирует коммиты на целевую ветку
  • Линейная история, каждый коммит сохранён
  • Нет merge-коммита

Настройка

В Настройки репозитория -> Слияние можно:

  • Разрешить/запретить каждую стратегию
  • Выбрать стратегию по умолчанию
  • Настроить автоудаление ветки после слияния

Очередь слияния (Merge Queue)

Автоматическое слияние с гарантией прохождения CI.

Как работает

  1. PR одобрен и готов к слиянию
  2. Автор нажимает «Добавить в очередь» вместо «Слить»
  3. GitRiver создаёт временную ветку с изменениями PR поверх текущего main
  4. Запускается CI на временной ветке
  5. Если CI прошёл - PR автоматически сливается
  6. Если упал - PR выводится из очереди с уведомлением

Зачем

Без очереди возможна ситуация:

  • PR A прошёл CI и ждёт слияния
  • PR B прошёл CI и ждёт слияния
  • PR A сливается - main изменился
  • PR B уже НЕ проверен на новом main - может сломать сборку

Очередь проверяет каждый PR на актуальном main перед слиянием.

Настройка

Настройки репозитория -> Слияние -> Очередь слияния:

  • Включить/выключить
  • Минимальный batch size (сколько PR объединять для проверки)
  • Максимальное время ожидания

Условия слияния

Настраиваются через Защиту веток (подробнее в разделе «Защита веток»):

УсловиеОписание
Обязательные проверки CIВсе указанные CI-задания должны пройти
Минимум одобренийКоличество approve от ревьюеров (1, 2, …)
Одобрение CODEOWNERХотя бы один CODEOWNER одобрил
Нет конфликтовВетка не конфликтует с целевой
Ветка актуальнаВетка содержит последний коммит целевой
Подписанные коммитыВсе коммиты подписаны GPG/SSH
Нерешённые тредыВсе треды комментариев должны быть решены
Линейная историяЗапрещены merge-коммиты в ветке

Уведомления

Участники PR получают уведомления:

  • Новый комментарий или ревью
  • Изменение статуса (одобрен, запрошены изменения, слит)
  • Упоминание через @
  • Назначение ревьюером
  • CI результат (passed / failed)

Каналы уведомлений настраиваются в профиле пользователя.