engineering-playbook/docs/advanced/01-gitflow-security.md

Архитектура GitFlow и Защита Инфраструктуры

Для Senior-разработчиков и DevOps-инженеров платформа REXNET функционирует по стандартам строгой изоляции и контроля качества кода.

1. Аппаратная защита веток (Branch Protection)

На всех корпоративных репозиториях настроена аппаратная защита главных веток (main, stage, dev), снять которую может только Owner:

• Disable Push (Блокировка прямого пуша): Ни один разработчик не может обновить ветку напрямую. Все изменения поступают исключительно через Pull Requests.
• Disable Force Push (Защита истории): Тотальный запрет на перезапись истории (git push --force). Любые коммиты иммунны к удалению.
• Required Approvals (Врата качества): Минимальное количество аппрувов для слияния установлено на 1. Права на аппрув жёстко ограничены белым списком (Allowlist), в который входят только Tech-Leads и Owners.
• Dismiss Stale Approvals (Защита от подмены): Любой новый коммит в уже открытый и одобренный Pull Request автоматически сбрасывает все предыдущие одобрения ревьюеров. Код всегда перепроверяется заново.

2. Стратегия ветвления (Environment Isolation)

Мы используем 3-уровневый безопасный конвейер развёртывания (Deployment Pipeline):

1. feature/* — Ветки разработчиков (Local Environment).
2. dev — Ветка интеграции. Сюда сливаются протестированные фичи. Код из этой ветки разворачивается в Development-среде для внутренних тестов команды.
3. stage — Предрелизная ветка (Staging Environment). Сюда попадают релиз-кандидаты. Среда Stage аппаратно и конфигурационно идентична боевой среде. Здесь работает команда QA.
4. main — Production. Абсолютно стабильный код, который видят конечные пользователи.

Переход кода между этими уровнями (dev -> stage -> main) осуществляется строго через создание новых Pull Requests с обязательным прохождением пайплайнов безопасности (CI/CD Pipeline).