Как код из main попадает в ветку release?

Как код из main попадает в ветку release

Процесс переноса кода из main в release связан с практикой версионирования и управления релизами. Это часть Git workflow для подготовки и управления production-релизами.

Git Flow модель

Основной подход — Git Flow, где есть несколько постоянных веток:

# Основные ветки:
# - main (master) — production-ready код
# - develop — разработка следующего релиза
# - release/* — подготовка релиза
# - hotfix/* — срочные исправления для production

# Ветки для разработки:
# - feature/* — новые функции
# - bugfix/* — исправления багов

Процесс выпуска релиза

1. Создание ветки release

# Работа в develop
git checkout develop
git pull origin develop

# Создаём ветку release
git checkout -b release/1.2.0

# Или с git flow инструментом
git flow release start 1.2.0

2. Подготовка к релизу в ветке release

# В ветке release могут быть только:
# - bump version
# - исправления критических багов
# - обновление CHANGELOG

# Пример: обновляем версию
# package.json: 1.1.9 -> 1.2.0

git add package.json
git commit -m "chore: bump version to 1.2.0"

3. Слияние в main (или master)

# Переходим в main
git checkout main
git pull origin main

# Мёржим ветку release
git merge release/1.2.0

# Создаём тег для версии
git tag -a v1.2.0 -m "Release version 1.2.0"

# Пушим в origin
git push origin main
git push origin v1.2.0

4. Синхронизация с develop

# Мёржим обратно в develop
git checkout develop
git merge release/1.2.0

# Пушим
git push origin develop

# Удаляем локальную ветку release
git branch -d release/1.2.0

# Удаляем удалённую ветку
git push origin -d release/1.2.0

Полный пример процесса

# 1. Разработка в develop завершена, началась подготовка к 2.0.0
git flow release start 2.0.0
# Создаёт ветку release/2.0.0 на основе develop

# 2. В ветке release обновляем версию и changelog
echo "2.0.0" > version.txt
echo "## Version 2.0.0\n- New feature X\n- Fix bug Y" >> CHANGELOG.md

git add version.txt CHANGELOG.md
git commit -m "chore: prepare release 2.0.0"

# 3. Тестируем в ветке release
# npm test, npm run build и т.д.

# 4. Мёржим в main и создаём тег
git flow release finish 2.0.0
# Это автоматически:
# - мёржит release/2.0.0 в main
# - создаёт тег v2.0.0
# - мёржит обратно в develop
# - удаляет ветку release/2.0.0

# 5. Пушим всё на origin
git push origin main develop --tags

Trunk-Based Development (современный подход)

Это альтернатива Git Flow, где код постоянно мёржится в main:

# 1. Работаем в feature ветке
git checkout -b feature/awesome-feature
# Разработка...
git add .
git commit -m "feat: implement awesome feature"

# 2. Создаём Pull Request в main
git push origin feature/awesome-feature
# PR проходит review и тесты

# 3. Мёржим в main
git merge feature/awesome-feature
git push origin main

# 4. Main всегда готов к релизу
# Для релиза просто создаём тег
git tag v1.2.0
git push origin v1.2.0

# Pipeline автоматически деплоит по тегу

GitHub Flow (для continuous deployment)

# 1. Создаём feature ветку
git checkout -b feature/new-api

# 2. Разработка и коммиты
git add .
git commit -m "feat: add new API endpoint"

# 3. Push и PR
git push origin feature/new-api
# Создаём PR на GitHub

# 4. Review и мёрж в main
# GitHub: Merge pull request

# 5. CI/CD автоматически деплоит из main
# (или при создании тега)

Автоматизация через CI/CD

# .github/workflows/release.yml
name: Release

on:
  push:
    branches:
      - main
    tags:
      - 'v*'

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      
      - name: Install dependencies
        run: npm install
      
      - name: Run tests
        run: npm test
      
      - name: Build
        run: npm run build
      
      - name: Deploy to production
        if: startsWith(github.ref, 'refs/tags/v')
        run: |
          VERSION=${GITHUB_REF#refs/tags/v}
          echo "Deploying version $VERSION to production"
          # Деплой команда

Semantic Versioning (SemVer)

# Версия: MAJOR.MINOR.PATCH
# 1.2.3
# |\ |  |
# | \ |  +-- PATCH: исправления ошибок (совместимо)
#    \ +---- MINOR: новые функции (совместимо)
#     +------ MAJOR: breaking changes (несовместимо)

# Примеры тегирования
git tag v1.0.0        # Initial release
git tag v1.0.1        # Bug fix
git tag v1.1.0        # New feature
git tag v2.0.0        # Breaking change

Release Notes и CHANGELOG

# CHANGELOG.md

## [2.0.0] - 2024-04-02
### Added
- New dashboard component
- API v2 support

### Changed
- Upgraded React to v19
- Updated styling system

### Fixed
- Memory leak in useEffect
- Performance issue in lists

### Removed
- Old API v1 endpoints (breaking change)

## [1.9.3] - 2024-03-28
### Fixed
- Critical security vulnerability

Автоматическое создание тегов

# npm-based проекты
# package.json содержит версию

# При разработке
npm version patch   # 1.0.0 -> 1.0.1
npm version minor   # 1.0.0 -> 1.1.0
npm version major   # 1.0.0 -> 2.0.0

# Это автоматически:
# - обновляет package.json
# - создаёт коммит
# - создаёт тег

git push origin main --tags

Практический пример: выпуск hotfix из main

# Ситуация: в production найдена критическая ошибка

# 1. Создаём hotfix ветку от main
git checkout main
git pull origin main
git checkout -b hotfix/critical-bug

# 2. Исправляем баг
# ... делаем fix ...
git add .
git commit -m "fix: critical security vulnerability"

# 3. Мёржим в main и создаём патч-версию
git checkout main
git merge hotfix/critical-bug
git tag v1.0.1

# 4. Мёржим обратно в develop
git checkout develop
git merge hotfix/critical-bug

# 5. Пушим всё
git push origin main develop --tags

# 6. Удаляем hotfix ветку
git branch -d hotfix/critical-bug

Заключение

Код попадает из main в release через несколько механизмов: Git Flow (где есть явная ветка release), Trunk-Based Development (все в main, релизы через теги), или GitHub Flow (main всегда готов). Процесс включает версионирование, создание тегов, CI/CD автоматизацию и управление CHANGELOG. Выбор подхода зависит от того, как часто выпускаешь релизы и нужна ли тебе параллельная разработка нескольких версий.