Навигация
Защита веток
Правила защиты веток, CODEOWNERS, очередь слияния, подписанные коммиты
Защита веток предотвращает случайные или несанкционированные изменения в важных ветках (main, release, production). В этом разделе - как настроить правила, CODEOWNERS и очередь слияния.
Зачем
Без защиты веток любой разработчик может:
- Запушить напрямую в
main, минуя ревью - Сделать force push и перезаписать историю
- Удалить ветку
Правила защиты решают эти проблемы: push только через пулл-реквесты, обязательное ревью, проверки CI.
Создание правила
- Откройте репозиторий -> «Настройки» (шестерёнка) -> «Защита веток»
- Нажмите «Новое правило»
- Укажите паттерн ветки - к каким веткам применять правило:
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
Как работает
- Разработчик открывает пулл-реквест
- GitRiver определяет, какие файлы изменены
- По CODEOWNERS находит ответственных
- Автоматически назначает их ревьюерами
Если в правиле защиты ветки включено «Обязательные ревью» - слить нельзя без одобрения от CODEOWNERS.
Очередь слияния (Merge Queue)
Проблема
Два пулл-реквеста одобрены и проверены CI. Но если слить первый - ветка main изменится, и второй может конфликтовать или сломать CI. Приходится перезапускать CI для каждого PR вручную.
Решение
Очередь слияния автоматизирует этот процесс:
- Разработчик нажимает «Добавить в очередь» (вместо «Слить»)
- GitRiver создаёт временную ветку, где мёржит PR с текущим
main - Запускает CI на этой ветке
- Если CI проходит - сливает в
main - Следующий PR в очереди проходит тот же процесс
Настройка
- Убедитесь, что для ветки настроено правило защиты с обязательными проверками CI
- Очередь слияния появляется автоматически - кнопка «Добавить в очередь» в пулл-реквесте
- Просмотр очереди: вкладка «Merge Queue» в репозитории
Теги
Теги используются для маркировки версий и триггеров CI.
Создание
- Через git:
git tag v1.0 && git push --tags - Через интерфейс: вкладка «Теги» в репозитории -> «Создать тег»
Использование в CI
on:
push:
tags: ['v*']
При push тега v1.0 - запустится workflow.
Связь с релизами
Тег можно связать с релизом: «Теги» -> выберите тег -> «Создать релиз». Добавьте описание и бинарные файлы.