Что такое доступ к иерархии ветки?

Доступ к иерархии ветки

Доступ к иерархии ветки (Branch Hierarchy Access) — это механизм управления правами доступа к различным уровням иерархии в системе контроля версий, таких как основная ветка (main), защищённые ветки (protected branches) и рабочие ветки разработчиков.

Концепция иерархии веток

В большинстве проектов используется иерархия веток:

main (production)
 ├── develop (integration branch)
 │   ├── feature/user-auth
 │   ├── feature/payment
 │   └── bugfix/login-issue
 └── release/v1.0
     ├── hotfix/critical-bug
     └── patch/security-fix

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

Уровни доступа в иерархии веток

1. Production Branch (main)

// main — самая критичная ветка, максимум ограничений
// Правила доступа:
// - Только администраторы могут мерджить напрямую
// - Требуется review минимум 2 разработчиков
// - Обязательна зелёная сборка (CI/CD)
// - Обязательно прошли все тесты
// - Требуется squash merge для чистоты истории

branch "main" {
    protect = true
    requireReview = 2
    requireCI = true
    requireTests = true
    allowedUsers = ["admin", "release-manager"]
}

2. Development Branch (develop)

// develop — интеграционная ветка, средний уровень ограничений
// Правила доступа:
// - Разработчики могут создавать pull requests
// - Требуется review 1 разработчика
// - Обязательна зелёная сборка
// - Менее строгие требования чем main

branch "develop" {
    protect = true
    requireReview = 1
    requireCI = true
    allowedUsers = ["developers", "admin"]
}

3. Feature/Release/Hotfix Branches

// Рабочие ветки — минимум ограничений
// Правила доступа:
// - Создатель может пушить напрямую
// - Другие разработчики могут создавать PR
// - CI/CD опционально
// - История может быть грязной (с merge commits)

branch "feature/*" {
    protect = false
    allowedUsers = ["creator", "developers"]
    canForcePush = true
}

Реализация доступа на GitHub

// GitHub Branch Protection Rules (в репозитории)
// Settings → Branches → Branch protection rules

// Для main:
// 1. Require pull request reviews before merging
//    - Number of approving reviews: 2
//    - Dismiss stale pull request approvals: true
//    - Require review from code owners: true
// 2. Require status checks to pass before merging
//    - Require branches to be up to date: true
//    - Require code quality checks: true
// 3. Require signed commits: true
// 4. Allow force pushes: false
// 5. Allow deletions: false

Контроль доступа в коде

Проверка прав в CI/CD пайплайне:

// Jenkins/GitLab CI pipeline
pipeline {
    stages {
        stage("Check Branch Access") {
            steps {
                script {
                    def branch = env.GIT_BRANCH
                    def user = env.GIT_COMMITTER_USER
                    
                    if (branch == "main") {
                        // Только администраторы могут мерджить в main
                        if (!isAdmin(user)) {
                            error "Access denied: Only admins can merge to main"
                        }
                    } else if (branch == "develop") {
                        // Разработчики могут мерджить в develop
                        if (!isDeveloper(user)) {
                            error "Access denied: Only developers can merge to develop"
                        }
                    }
                }
            }
        }
    }
}

Примеры стратегий доступа

Простая модель (маленькая команда):

// Две ветки: main и develop
main:      // production
  - Protection: true
  - Reviews: 1
  - Approvers: anyone
  - Allowed users: [developers, admins]

develop:   // development
  - Protection: false
  - Allowed users: [developers, admins]

Сложная модель (большая команда):

main:              // production
  - Protection: true
  - Reviews: 2 (from code-owners)
  - Status checks: required
  - Signed commits: required
  - Allowed users: [release-manager, lead-dev]

develop:           // integration
  - Protection: true
  - Reviews: 1
  - Status checks: required
  - Allowed users: [developers, admins]

feature/*:         // feature development
  - Protection: false
  - Allowed users: [creator, team-leads]

hotfix/*:          // emergency fixes
  - Protection: false
  - Allowed users: [creator, senior-devs]

Управление доступом через роли

// Определение ролей в системе
enum BranchRole {
    ADMIN("admin"),           // Полный доступ
    RELEASE_MANAGER("release"),  // Может мерджить в main
    LEAD_DEVELOPER("lead"),    // Может пушить в develop
    DEVELOPER("dev"),         // Может пушить в feature
    READONLY("readonly");      // Только чтение
}

// Проверка прав
boolean canMergeTo(String branch, BranchRole role) {
    return switch (branch) {
        case "main" -> 
            role == BranchRole.ADMIN || role == BranchRole.RELEASE_MANAGER;
        case "develop" -> 
            role == BranchRole.ADMIN || role == BranchRole.LEAD_DEVELOPER || 
            role == BranchRole.DEVELOPER;
        case "feature" -> 
            role != BranchRole.READONLY;
        default -> false;
    };
}

Практические преимущества

Безопасность кода:

• Предотвращает случайные изменения в production
• Гарантирует review перед мерджингом
• Контролирует кто может мерджить

Качество кода:

• Требует прохождения тестов
• Требует статического анализа
• Ограничивает прямые пушы в критичные ветки

Управление командой:

• Разные ожидания для разных веток
• Четкие правила для всей команды
• Упрощает onboarding новых разработчиков

Типичная рабочая инструкция

// 1. Создаёшь feature ветку от develop
git checkout -b feature/my-feature develop

// 2. Работаешь в своей ветке (нет ограничений)
git push origin feature/my-feature

// 3. Создаёшь PR в develop
// - Требуется 1 review
// - Должны пройти тесты

// 4. После одобрения PR, код мерджится в develop
// - Автоматически запускается CI/CD

// 5. Release Manager создаёт PR из develop в main
// - Требуется 2 reviews
// - Обязательны все проверки
// - Только release manager может мерджить

// 6. После мерджа в main автоматически деплоится в production

Доступ к иерархии веток — критичный механизм для обеспечения качества кода и безопасности в больших командах разработки.