GitRiver GitRiver
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.

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

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