Github Flow 브랜치 전략 개선 사례

문제 상황

기존에 사용하던 Github Flow 브랜치 전략에서 다음과 같은 문제점들이 발생했다.

gitGraph
    commit id: "Initial"
    branch develop
    checkout develop
    commit id: "Dev setup"
    branch feature/A
    checkout feature/A
    commit id: "Feature A dev"
    branch feature/B
    checkout feature/B
    commit id: "Feature B dev"
    checkout develop
    branch release/sprint-1
    checkout release/sprint-1
    merge feature/A
    merge feature/B
    commit id: "QA testing"
    checkout main
    merge release/sprint-1
    commit id: "Release"

주요 문제점

1. 스프린트 일정 변경 시 롤백 이슈

   • 릴리즈 예정이었던 기능이 제외될 경우, release 브랜치에서 해당 작업을 일일이 롤백해야 함

2. QA 빌드 중복 문제

   • QA 완료 시점이 다른 feature들로 인해 여러 개의 빌드를 동시에 관리해야 함

   • release 브랜치와 개별 feature 브랜치의 별도 빌드 필요

해결 방안

gitGraph
    commit id: "Initial"
    branch develop
    checkout develop
    commit id: "Auto sync"
    checkout main
    branch feature/A
    checkout feature/A
    commit id: "Feature A dev"
    checkout main
    branch feature/B
    checkout feature/B
    commit id: "Feature B dev"
    checkout main
    branch release
    checkout release
    merge feature/A
    commit id: "QA Feature A"
    checkout main
    merge feature/A
    commit id: "Release A"
    checkout release
    merge feature/B
    commit id: "QA Feature B"
    checkout main
    merge feature/B
    commit id: "Release B"

개선된 프로세스

1. Feature 브랜치는 main에서만 분기

2. Github Action을 통한 자동화

# .github/workflows/auto-sync.yml 예시
name: Auto Sync to Develop
on:
  push:
    branches: [ feature/** ]
jobs:
  sync:
    runs-on: ubuntu-latest
    steps:
      - name: Auto merge to develop
        # feature 브랜치 push 시 자동으로 develop에 반영

3. 개별 feature QA 프로세스

   • QA가 필요한 feature만 release 브랜치에 merge

   • QA 완료 후 해당 feature를 main에 개별 merge

   • 스프린트 일정과 무관하게 독립적인 릴리즈 가능

효과

브랜치 전략 개선을 통해 다음과 같은 성과를 달성했습니다:

• 스프린트 일정 변경에 유연한 대응 가능

• QA 프로세스 간소화 및 효율성 향상

• 개발팀의 생산성 및 배포 안정성 확보

이러한 개선을 통해 팀의 개발 워크플로우가 크게 향상되었으며, 더 안정적이고 효율적인 릴리즈 프로세스를 구축할 수 있었습니다.