Перейти к содержимому
GitRiverGitRiver
EN
Навигация

Защита веток

Правила защиты веток, CODEOWNERS, очередь слияния, подписанные коммиты

Защита веток предотвращает случайные или несанкционированные изменения в важных ветках (main, release, production). В этом разделе - как настроить правила, CODEOWNERS и очередь слияния.

Зачем

Без защиты веток любой разработчик может:

  • Запушить напрямую в main, минуя ревью
  • Сделать force push и перезаписать историю
  • Удалить ветку

Правила защиты решают эти проблемы: push только через пулл-реквесты, обязательное ревью, проверки CI.

Создание правила

  1. Откройте репозиторий -> «Настройки» (шестерёнка) -> «Защита веток»
  2. Нажмите «Новое правило»
  3. Укажите паттерн ветки - к каким веткам применять правило:
    • main - точное совпадение
    • release/* - все ветки вида release/1.0, release/2.0
    • * - все ветки

Доступные ограничения

Настройка Что делает
Запретить push Изменения только через пулл-реквесты
Запретить force push Нельзя перезаписать историю
Запретить удаление Ветку нельзя удалить
Обязательные проверки CI Пулл-реквест нельзя слить, если CI не прошёл
Обязательные ревью Нужно указанное количество одобрений (approve)
Блокировать при отклонённых ревью Если кто-то запросил изменения - слить нельзя
Требовать актуальность ветки Ветка должна быть обновлена до целевой перед слиянием
Требовать подписанные коммиты Все коммиты должны быть подписаны GPG

Белый список

Для каждого правила можно указать пользователей или команды, которым разрешён прямой push или force push, несмотря на ограничения. Это полезно для CI-ботов или release-менеджеров.

CODEOWNERS

CODEOWNERS автоматически назначает ревьюеров для пулл-реквестов в зависимости от того, какие файлы были изменены.

Настройка

Создайте файл CODEOWNERS в корне репозитория (или в .gitriver/):

# Файлы Go - ревью команды backend
*.go @backend-team

# Frontend - ревью конкретного пользователя
src/frontend/** @alice

# Dockerfile и CI - ревью DevOps
Dockerfile @devops-team
.gitriver/** @devops-team

# Всё остальное - maintainer
* @bob

Как работает

  1. Разработчик открывает пулл-реквест
  2. GitRiver определяет, какие файлы изменены
  3. По CODEOWNERS находит ответственных
  4. Автоматически назначает их ревьюерами

Если в правиле защиты ветки включено «Обязательные ревью» - слить нельзя без одобрения от CODEOWNERS.

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

Проблема

Два пулл-реквеста одобрены и проверены CI. Но если слить первый - ветка main изменится, и второй может конфликтовать или сломать CI. Приходится перезапускать CI для каждого PR вручную.

Решение

Очередь слияния автоматизирует этот процесс:

  1. Разработчик нажимает «Добавить в очередь» (вместо «Слить»)
  2. GitRiver создаёт временную ветку, где мёржит PR с текущим main
  3. Запускает CI на этой ветке
  4. Если CI проходит - сливает в main
  5. Следующий PR в очереди проходит тот же процесс

Настройка

  1. Убедитесь, что для ветки настроено правило защиты с обязательными проверками CI
  2. Очередь слияния появляется автоматически - кнопка «Добавить в очередь» в пулл-реквесте
  3. Просмотр очереди: вкладка «Merge Queue» в репозитории

Теги

Теги используются для маркировки версий и триггеров CI.

Создание

  • Через git: git tag v1.0 && git push --tags
  • Через интерфейс: вкладка «Теги» в репозитории -> «Создать тег»

Использование в CI

on:
  push:
    tags: ['v*']

При push тега v1.0 - запустится workflow.

Связь с релизами

Тег можно связать с релизом: «Теги» -> выберите тег -> «Создать релиз». Добавьте описание и бинарные файлы.