Какие шаблоны с ветками использовал?

Стратегии Git ветвления: практический опыт

За 10+ лет работал с разными моделями ветвления. Разберу которые использовал, их плюсы и минусы.

1. Git Flow - классический подход

Использовал это в больших корпоративных проектах:

main (production)           feature/login
  |                          |
  |-- v1.2.0 (tag)           |
release/1.2.0 --------- merge---------
  |                          
develop (staging)          feature/payment
  |                          |
  |-- merge--------branch-fork
  |                          
hotfix/bug-fix ---------- merge ------
  |                          

# Git Flow workflow

# 1. Создаём фичу от develop
git checkout -b feature/user-authentication develop

# 2. Разрабатываем
# ...
git add .
git commit -m "feat: add user authentication"

# 3. Создаём pull request в develop
git push origin feature/user-authentication
# На GitHub: Create PR develop <- feature/user-authentication

# 4. После merge в develop
git checkout develop
git pull
git branch -d feature/user-authentication

# 5. Готовим release
git checkout -b release/1.0.0 develop
# Fix только критичные баги, version bump

# 6. Merge в main и develop
git checkout main
git merge --no-ff release/1.0.0
git tag -a v1.0.0 -m "Release version 1.0.0"

git checkout develop
git merge --no-ff release/1.0.0

# 7. Hotfix для production
git checkout -b hotfix/critical-bug main
# Fix
git checkout main
git merge --no-ff hotfix/critical-bug
git tag -a v1.0.1 -m "Hotfix"
git checkout develop
git merge --no-ff hotfix/critical-bug

Плюсы:

• Ясная структура и роли веток
• Хороша для scheduled releases
• Production всегда стабилен

Минусы:

• Много merge операций
• Conflict-prone при частых изменениях
• Долгие PR reviews (develop может быть старым)
• Медленный цикл доставки

2. GitHub Flow - простой и современный

Использовал это в стартапах и быстро-растущих командах:

main (production)
  |
  |-- feature/payment (PR)
  |-- feature/email (PR)
  |-- bugfix/validation (PR)
  |

# GitHub Flow workflow

# 1. Создаём ветку от main
git checkout -b feature/add-payment-gateway

# 2. Разрабатываем, коммитим, пушим
git add .
git commit -m "feat: add stripe payment integration"
git push origin feature/add-payment-gateway

# 3. Создаём PR
# На GitHub: Create PR main <- feature/add-payment-gateway

# 4. Code review и discussion
# Добавляем изменения если нужно

# 5. Когда одобрено - merge to main
# После merge автоматически деплоится

git checkout main
git pull
git branch -d feature/add-payment-gateway

Плюсы:

• Простая и понятная модель
• Быстрый цикл разработки
• Хорошо для CI/CD
• Меньше конфликтов

Минусы:

• Нет явного staging окружения
• Требует идеальных тестов
• Сложнее откатывать в production

3. Trunk-Based Development - для high-performing teams

Использовал в компаниях с очень высокой культурой разработки:

main (production)
  |
  |-- short-lived feature branches (< 1 день)
  |-- continuous small commits
  |

# Trunk-Based Development workflow

# 1. Создаём SHORT-LIVED ветку
git checkout -b feature/add-profile-validation

# 2. Работаем ОЧЕНЬ эффективно (< 1 дня)
# Коммиты маленькие и логичные
git add .
git commit -m "feat: add email validation"
git commit -m "feat: add profile age validation"
git commit -m "test: add validation tests"

# 3. Code review MUST BE FAST
git push origin feature/add-profile-validation
# PR жилась в течение часа

# 4. Merge и delete
git checkout main
git pull
git merge --squash feature/add-profile-validation
git commit -m "feat: add profile validation (#123)"
git push
git branch -d feature/add-profile-validation

# Требования для успеха:
# 1. Feature flags для незавершённых фич
# 2. Excellent CI/CD pipeline
# 3. Strong code review culture
# 4. Daily commits to main

# Feature flags для trunk-based development
from django.conf import settings

class FeatureFlags:
    NEW_PROFILE_VALIDATION = True
    EXPERIMENTAL_ML_RANKING = False
    BETA_NEW_UI = True

def get_user_features(user):
    flags = {}
    flags['NEW_PROFILE_VALIDATION'] = FeatureFlags.NEW_PROFILE_VALIDATION
    flags['EXPERIMENTAL_ML_RANKING'] = user.is_beta_tester and FeatureFlags.EXPERIMENTAL_ML_RANKING
    flags['BETA_NEW_UI'] = user.enrolled_beta and FeatureFlags.BETA_NEW_UI
    return flags

def validate_profile(profile, user):
    if get_user_features(user).get('NEW_PROFILE_VALIDATION'):
        return new_validate_profile(profile)
    else:
        return old_validate_profile(profile)

Плюсы:

• Минимальные merge conflicts
• Быстрый feedback loop
• Проще отследить историю
• Меньше merge commits

Минусы:

• Требует отличной дисциплины команды
• Необходимы хорошие feature flags
• Требует очень быстрых code reviews
• Не подходит новичкам

4. GitLab Flow - балан между простотой и структурой

Успешная гибридная модель (использовал в mid-size компаниях):

production
  |
pre-production
  |
staging/testing
  |
main/development
  |
  |-- feature/login
  |-- feature/payments

# GitLab Flow - для разных окружений

# 1. Фича от main
git checkout -b feature/oauth-integration main

# 2. Push и MR
git push origin feature/oauth-integration
# На GitLab: Create MR main <- feature/oauth-integration

# 3. После merge в main
# Auto-deploy to staging

# 4. Promote to production когда готово
git checkout production
git merge main
# Auto-deploy to production

# Если нужно быстро исправить production:
git checkout -b hotfix/urgent production
# Fix
git merge production -> main -> staging

Лучший выбор когда:

• Несколько окружений (dev, staging, production)
• Разные скорости развёртывания
• Нужна стабильность production

5. Что я использую сейчас (2024)

Комбинация GitHub Flow + Trunk-Based:

# Рекомендуемая стратегия

class BranchStrategy:
    """
    GitHub Flow + Trunk-Based для современных команд
    """
    
    rules = {
        'main_branch': {
            'name': 'main',
            'protection': True,
            'require_pr': True,
            'require_status_checks': True,
            'auto_deploy': True,
            'production': True
        },
        
        'feature_branches': {
            'naming': 'feature/*, bugfix/*, hotfix/*',
            'lifetime': '< 3 days',
            'max_files_changed': 50,  # Smaller PRs
            'max_commits': 10,
            'source': 'main',
            'delete_after_merge': True
        },
        
        'code_review': {
            'require_approvals': 2,
            'auto_dismiss_stale': True,
            'sla': '4 hours',
            'require_passing_tests': True,
            'require_coverage': '> 80%'
        },
        
        'merge_strategy': {
            'method': 'squash',  # Один commit в main
            'auto_delete_head_branch': True
        },
        
        'versioning': {
            'scheme': 'semantic versioning',
            'tag_on_release': True,
            'auto_changelog': True
        }
    }

6. Инструменты для управления ветками

# Git aliases для удобства
[alias]
    co = checkout
    br = branch
    ci = commit
    st = status
    new-feature = "!git checkout -b feature/$1 main"
    new-bugfix = "!git checkout -b bugfix/$1 main"
    sync = "!git fetch origin && git rebase origin/main"
    cleanup = "!git branch -d $(git branch --merged | grep -v '*')"

# GitHub CLI
gh pr create --title "My feature" --body "Description"
gh pr checkout 123
gh pr merge 123 --squash
gh pr list --state open

# Git hooks для качества
# .husky/pre-commit
npm run lint-staged
pitest

# .husky/pre-push
npm run test:full

7. Проблемы которые решал

Конфликты при merge

# Часто случается в Git Flow
git merge develop
# Конфликт!

# Решение
git status  # Посмотрим конфликтующие файлы
# Ручное разрешение
git add .
git commit -m "Resolved merge conflicts"

Случайный push в main

# Защита: branch protection rules на GitHub
# Требуем:
# - PR review
# - Passing checks
# - Updated with main

# Или локально
git config --local 'receive.denyCurrentBranch' 'updateInstead'

Потеря коммита

git reflog  # Найти потерянный коммит
git checkout <lost-commit>
git checkout -b recovered-branch

8. Мои рекомендации

Для стартапов (< 10 разработчиков):

• Используй GitHub Flow
• Все деплоятся в production
• Требуй хорошие тесты

Для растущей команды (10-50):

• GitHub Flow + staging branch
• Feature flags для незавершённых фич
• Code review SLA: 24 часа

Для зрелой команды (50+):

• Trunk-Based Development
• Очень строгие стандарты quality
• Автоматизированные проверки

Для корпораций с scheduled releases:

• Git Flow или GitLab Flow
• Явные версии и release notes
• Долгие maintenance branches

Главное: выбери модель которая работает для твоей команды и придерживайся её последовательно.