Git의 Release Branch — 정의, 목적 및 워크플로

Git에서 Release Branch란

Release Branch(릴리스 브랜치)는 팀이 현재 기능 세트가 릴리스 준비가 되었다고 판단할 때 develop에서 생성되는 Git Flow의 임시 브랜치입니다. 이 브랜치는 최종 릴리스 준비가 진행되는 동안(몇 시간에서 며칠까지) 존재합니다.

릴리스 브랜치의 주요 목적은 다음 버전 개발을 중단하지 않고 특정 기능 세트를 릴리스용으로 고정하는 것입니다. 릴리스 브랜치가 배포 준비 중인 동안 다른 개발자는 다음 릴리스를 위해 develop에 기능 브랜치를 계속 병합할 수 있습니다.

릴리스 브랜치에서는 새 기능이 생성되지 않습니다. 버그 수정, 애플리케이션 버전 업데이트, 현지화 및 문서화만 수행됩니다. 모든 작업이 완료되면 릴리스 브랜치는 main(릴리스로 표시)과 develop(버그 수정이 향후 버전에 반영되도록)에 병합됩니다.

Atlassian, 2024에 따르면, 릴리스 브랜치는 정기적인 릴리스 주기가 있는 프로젝트에 매우 중요하며, 릴리스 프로세스의 예측 가능성과 안정성을 보장합니다.

릴리스 브랜치의 수명 주기

릴리스 브랜치의 수명 주기는 생성부터 삭제까지 여러 단계로 구성됩니다. 각 단계를 이해하면 팀이 작업을 동기화하고 실수를 방지하는 데 도움이 됩니다.

1. 생성 — develop의 최신 커밋에서 release/2.5.0이라는 브랜치가 생성됩니다. develop은 다음 버전을 위한 기능 브랜치를 계속 수락합니다.
2. 준비 — 릴리스 브랜치에서 build.gradle, Info.plist 및 기타 구성 파일의 앱 버전이 업데이트됩니다.
3. 버그 수정 — 최종 테스트 중 발견된 중요한 오류가 수정됩니다. 버그만 수정하며 새 기능은 없습니다.
4. 최종 테스트 — QA 팀이 릴리스 브랜치에서 회귀 테스트를 수행합니다. 새 버그는 동일한 브랜치에서 수정을 위해 전송됩니다.
5. main에 병합 — 릴리스 브랜치가 --no-ff 플래그와 함께 main에 병합됩니다. 릴리스 태그가 생성됩니다: v2.5.0.
6. develop에 병합 — 릴리스 브랜치가 develop에 다시 병합되어 릴리스의 버그 수정이 현재 개발에 반영됩니다.
7. 삭제 — 작업이 완료되었으므로 릴리스 브랜치가 로컬 및 원격에서 삭제됩니다.

6단계(develop으로의 병합 백)는 종종 잊혀지지만 매우 중요합니다. 이 단계가 없으면 릴리스에서 수행된 버그 수정이 develop에 반영되지 않으며, 다음 릴리스에서 동일한 오류가 다시 나타날 수 있습니다.

릴리스 브랜치 단계의 일반적인 기간

릴리스 브랜치의 수명은 릴리스의 복잡성과 develop의 코드 품질에 따라 달라집니다. 중간 규모 모바일 애플리케이션의 경우 준비에 평균 2~5영업일이 소요됩니다.

릴리스 브랜치에서 수행되는 작업

릴리스 브랜치에서는 엄격하게 제한된 작업 집합만 수행됩니다. 이 목록에서 벗어나면 Git Flow 모델을 위반하고 릴리스 안정성에 위험을 초래합니다.

새 기능 금지 규칙은 릴리스 브랜치에서 가장 중요합니다. 기능이 릴리스에 맞춰 준비되지 않은 경우 다음 주기를 기다립니다. 미완성 기능을 릴리스 브랜치에 강제로 넣으려는 시도는 기한 초과와 프로덕션 버그의 주요 원인입니다.

모바일 프로젝트에서 버전 업데이트

릴리스 브랜치에서는 애플리케이션 버전 번호가 필수로 업데이트됩니다. Android의 경우 build.gradle의 versionCode 및 versionName 필드이며, iOS의 경우 Info.plist의 CFBundleShortVersionString입니다.

// build.gradle(앱 수준) — 릴리스 브랜치에서 버전 업데이트
android {
    defaultConfig {
        versionCode 42
        versionName "2.5.0"
    }
}

// iOS의 경우 — Info.plist 업데이트
// CFBundleShortVersionString = 2.5.0
// CFBundleVersion = 42

Release와 hotfix의 차이점

초보 개발자는 release와 hotfix 브랜치를 자주 혼동하지만, 그 목적은 근본적으로 다릅니다. 잘못된 브랜치 유형을 선택하면 중요한 수정이 지연되거나 릴리스 프로세스가 중단될 수 있습니다.

• 소스 — release는 develop에서 생성되고, hotfix는 main에서 생성됩니다. 이것이 다른 모든 것을 결정하는 주요 차이점입니다.
• 긴급성 — release는 계획적입니다. 팀이 준비 시작 시기를 결정합니다. Hotfix는 긴급합니다. 프로덕션 문제를 즉시 수정해야 합니다.
• 내용 — release에는 여러 수정 사항과 버전 업데이트가 포함될 수 있습니다. Hotfix에는 하나의 중요한 수정 사항만 포함됩니다.
• 병합 — release는 main과 develop에 병합됩니다. Hotfix도 main과 develop에 병합되지만 우선적으로 수행됩니다.
• 수명 — release는 1~7일 동안 지속됩니다. Hotfix는 30분~1일 동안 지속됩니다.

릴리스 준비 중(릴리스 브랜치 내)에 버그가 발견되면 일반 버그 수정입니다. 프로덕션(main)에서 버그가 발견되면 hotfix이며, 릴리스 브랜치가 이미 존재하더라도 main에서 생성됩니다.

릴리스 브랜치 명명 규칙

통합된 릴리스 브랜치 명명 표준은 저장소 탐색을 간소화하고 CI/CD 시스템이 브랜치가 릴리스 프로세스에 속하는지 자동으로 감지할 수 있게 합니다.

• release/X.Y.Z — 표준 Git Flow 형식. X.Y.Z는 릴리스 버전입니다. 예: release/2.5.0.
• release/이름 — 릴리스 코드명을 사용하는 대체 형식. 예: release/merlin.
• release/날짜 — 릴리스 날짜를 사용하는 형식. 버전이 날짜보다 중요하므로 거의 사용되지 않습니다. 예: release/2024-12-01.

release/X.Y.Z 형식이 선호됩니다. 브랜치를 릴리스에 할당될 버전 번호와 명시적으로 연결하기 때문입니다. 이렇게 하면 CI/CD 스크립트를 통한 검색 및 자동 처리가 간소화됩니다.

develop으로의 병합 백 전략

릴리스 브랜치의 develop으로의 병합 백은 가장 중요하면서도 가장 자리 건너뛰어지는 작업 중 하나입니다. 이 작업이 없으면 릴리스 브랜치에서 수행된 모든 버그 수정이 릴리스 버전에만 남고 다음 릴리스 주기에 반영되지 않습니다.

병합 백 프로세스는 릴리스 브랜치가 이미 main에 병합된 후에 수행됩니다. 먼저 release가 develop에 병합된 다음 삭제됩니다. 이렇게 하면 develop에 릴리스 준비 중 수행된 모든 수정 사항이 포함됩니다.

병합 백 후 충돌이 발생할 수 있습니다. 특히 동일한 파일을 수정한 새 기능 브랜치가 이미 develop에 나타난 경우 그렇습니다. 릴리스 담당 개발자가 이러한 충돌을 해결하고 develop을 서버에 푸시합니다.

일부 팀은 기록을 선형으로 유지하기 위해 병합 백에 병합 대신 리베이스를 사용합니다. 그러나 병합이 develop에 더 안전하며, 다른 개발자가 이미 사용 중인 커밋 기록을 다시 쓰지 않기 때문입니다.

릴리스 작업 명령어 예시

모바일 애플리케이션 버전 2.5.0의 성공적인 릴리스 후 릴리스 브랜치 작업의 전체 주기(생성부터 삭제까지)를 살펴보겠습니다.

# 1. develop에서 릴리스 브랜치 생성
git checkout develop
git pull origin develop
git checkout -b release/2.5.0

# 2. 버전 및 버그 수정 업데이트
git add build.gradle
git commit -m "Bump version to 2.5.0"

# 3. 버그 수정(버그 수정만)
git add src/fix/
git commit -m "Fix crash on payment screen"

# 4. 릴리스 브랜치를 서버에 푸시
git push origin release/2.5.0

# 5. release를 main에 병합
git checkout main
git pull origin main
git merge --no-ff release/2.5.0
git tag -a v2.5.0 -m "Release 2.5.0"
git push origin main --tags

# 6. develop에 병합 백
git checkout develop
git merge --no-ff release/2.5.0
git push origin develop

# 7. 릴리스 브랜치 삭제
git branch -d release/2.5.0
git push origin --delete release/2.5.0

명령어 5와 6(이중 병합)은 매우 중요합니다. 먼저 main이 릴리스 코드와 태그를 받고, 그 다음 develop이 릴리스의 버그 수정과 동기화됩니다. 6단계를 건너뛰면 릴리스의 수정 사항이 다음 개발 주기에 반영되지 않습니다.

릴리스 프로세스 자동화

정기적인 릴리스가 있는 모바일 프로젝트의 경우 릴리스 브랜치 생성 및 버전 업데이트 프로세스를 CI/CD 스크립트를 통해 자동화할 수 있습니다. GitHub Actions를 사용하면 버튼 클릭 한 번으로 자동 버전 업데이트와 함께 릴리스 브랜치를 생성하는 워크플로를 만들 수 있습니다.

정기적인 릴리스가 있는 모바일 프로젝트의 경우 릴리스 브랜치 생성 및 버전 업데이트 프로세스를 CI/CD 스크립트를 통해 자동화할 수 있습니다. GitHub Actions를 사용하면 버튼 클릭 한 번으로 자동 버전 업데이트와 함께 릴리스 브랜치를 생성하는 워크플로를 만들 수 있습니다.

# GitHub Actions — 릴리스 브랜치 생성 자동화
name: Create Release Branch

on:
  workflow_dispatch:
    inputs:
      version:
        description: 'Release version (e.g. 2.5.0)'
        required: true

jobs:
  create-release:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Create release branch
        run: |
          git checkout develop
          git checkout -b release/${{ inputs.version }}
          git push origin release/${{ inputs.version }}