[GitHub 100일 챌린지] Day 50 - 브랜치 전략 (Git Flow)

100일 챌린지 Day 50 - 실무에서 사용하는 Git 브랜치 전략을 배웁니다.

배울 내용

1. Git Flow란
2. GitHub Flow
3. 브랜치 전략 선택하기

---

Topic1. Git Flow란

체계적인 릴리스 관리를 위한 브랜치 전략입니다.

Git Flow 브랜치 구조

5가지 브랜치 타입:

gitGraph
    commit id: "Initial"
    branch develop
    checkout develop
    commit id: "Dev 1"
    branch feature/login
    checkout feature/login
    commit id: "Login work"
    checkout develop
    merge feature/login
    branch release/1.0
    checkout release/1.0
    commit id: "RC fixes"
    checkout main
    merge release/1.0 tag: "v1.0"
    checkout develop
    merge release/1.0
    branch hotfix/security
    checkout hotfix/security
    commit id: "Fix CVE"
    checkout main
    merge hotfix/security tag: "v1.0.1"
    checkout develop
    merge hotfix/security

브랜치별 역할:

1. main (master)
   - 프로덕션 코드
   - 항상 배포 가능
   - 태그로 버전 관리

2. develop
   - 개발 메인 브랜치
   - 다음 릴리스 준비
   - feature들이 병합됨

3. feature/*
   - 새 기능 개발
   - develop에서 분기
   - develop으로 병합

4. release/*
   - 릴리스 준비
   - develop에서 분기
   - main과 develop에 병합

5. hotfix/*
   - 긴급 버그 수정
   - main에서 분기
   - main과 develop에 병합

Git Flow 워크플로우

기능 개발 흐름:

# 1. develop에서 feature 생성
git checkout develop
git pull origin develop
git checkout -b feature/user-profile

# 2. 기능 개발
git add .
git commit -m "feat: Add user profile page"

# 3. develop에 병합
git checkout develop
git merge --no-ff feature/user-profile
git push origin develop
git branch -d feature/user-profile

릴리스 흐름:

# 1. release 브랜치 생성
git checkout develop
git checkout -b release/1.0.0

# 2. 버전 정보 업데이트, 버그 수정
echo "1.0.0" > VERSION
git commit -am "chore: Bump version to 1.0.0"

# 3. main에 병합 (릴리스)
git checkout main
git merge --no-ff release/1.0.0
git tag -a v1.0.0 -m "Release 1.0.0"

# 4. develop에도 병합 (버그 수정 반영)
git checkout develop
git merge --no-ff release/1.0.0

# 5. release 브랜치 삭제
git branch -d release/1.0.0

핫픽스 흐름:

# 1. main에서 hotfix 생성
git checkout main
git checkout -b hotfix/security-patch

# 2. 버그 수정
git commit -am "fix: Security vulnerability patch"

# 3. main에 병합
git checkout main
git merge --no-ff hotfix/security-patch
git tag -a v1.0.1 -m "Hotfix 1.0.1"

# 4. develop에도 병합
git checkout develop
git merge --no-ff hotfix/security-patch

# 5. hotfix 브랜치 삭제
git branch -d hotfix/security-patch

---

Topic2. GitHub Flow

단순하고 빠른 배포를 위한 브랜치 전략입니다.

GitHub Flow 구조

2가지 브랜치 타입:

gitGraph
    commit id: "C1"
    branch feature/login
    checkout feature/login
    commit id: "Add login"
    checkout main
    merge feature/login tag: "Deploy"
    branch feature/payment
    checkout feature/payment
    commit id: "Add payment"
    checkout main
    merge feature/payment tag: "Deploy"

GitHub Flow 원칙:

1. main 브랜치는 항상 배포 가능
2. 새 작업은 브랜치에서
3. 정기적으로 push
4. Pull Request로 리뷰
5. 리뷰 후 main에 병합
6. 병합 즉시 배포

GitHub Flow 워크플로우

전체 흐름:

# 1. feature 브랜치 생성
git checkout main
git pull origin main
git checkout -b feature/search

# 2. 작업 + 정기적 push
git add .
git commit -m "feat: Add search functionality"
git push origin feature/search

# 3. Pull Request 생성
gh pr create --title "Add search feature" \
  --body "Implements user search with filters"

# 4. 리뷰 + 수정
# (GitHub에서 리뷰)
git add .
git commit -m "fix: Address review comments"
git push origin feature/search

# 5. main에 병합
gh pr merge --squash

# 6. 즉시 배포
# (CI/CD 자동 배포)

# 7. 브랜치 정리
git checkout main
git pull origin main
git branch -d feature/search

GitHub Flow 장점:

✅ 단순함 (브랜치 2개만)
✅ 빠른 배포
✅ CI/CD 친화적
✅ 배우기 쉬움
✅ 작은 팀에 적합

GitHub Flow 단점:

❌ 복잡한 릴리스 관리 어려움
❌ 여러 버전 동시 유지 어려움
❌ 릴리스 스케줄 관리 어려움

---

Topic3. 브랜치 전략 선택하기

프로젝트 특성에 맞는 전략을 선택합니다.

Git Flow vs GitHub Flow

비교표:

┌─────────────┬──────────────┬───────────────┐
│   특성       │  Git Flow    │ GitHub Flow   │
├─────────────┼──────────────┼───────────────┤
│ 브랜치 수    │ 5개          │ 2개           │
│ 복잡도       │ 높음         │ 낮음          │
│ 릴리스 관리  │ 체계적       │ 단순          │
│ 배포 속도    │ 느림         │ 빠름          │
│ 학습 곡선    │ 가파름       │ 완만          │
└─────────────┴──────────────┴───────────────┘

선택 기준

Git Flow 적합한 경우:

✅ 정해진 릴리스 주기 (월간/분기별)
✅ 여러 버전 동시 유지보수
✅ 엄격한 품질 관리
✅ 큰 팀 (10명 이상)
✅ 패키지/라이브러리 개발

예시:
- 엔터프라이즈 소프트웨어
- 모바일 앱 (앱스토어 심사)
- On-premise 솔루션

GitHub Flow 적합한 경우:

✅ 지속적 배포 (CD)
✅ 웹 서비스 / SaaS
✅ 빠른 반복 개발
✅ 작은 팀 (< 10명)
✅ 단일 프로덕션 버전

예시:
- 웹 애플리케이션
- API 서비스
- 스타트업 프로젝트

실무 팁

Git Flow 실무 적용:

# git-flow 도구 사용
brew install git-flow

# 초기화
git flow init

# feature 시작/완료
git flow feature start login
git flow feature finish login

# release 시작/완료
git flow release start 1.0.0
git flow release finish 1.0.0

# hotfix 시작/완료
git flow hotfix start security-patch
git flow hotfix finish security-patch

GitHub Flow 실무 적용:

# 1. 브랜치 보호 규칙 설정
# Settings → Branches → Add rule
# - Require pull request reviews
# - Require status checks to pass
# - Require branches to be up to date

# 2. CI/CD 파이프라인 설정
# .github/workflows/deploy.yml
name: Deploy
on:
  push:
    branches: [main]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Deploy
        run: ./deploy.sh

# 3. 자동 배포 후 모니터링

혼합 전략:

많은 팀이 두 전략을 혼합해서 사용:

1. 개발: GitHub Flow (빠른 개발)
2. 릴리스: Git Flow (체계적 관리)

예시:
- develop: 개발 메인 브랜치
- main: 프로덕션
- feature/*: GitHub Flow 방식으로 개발
- release/*: 필요 시에만 생성

---

정리

오늘 배운 내용:

1. Git Flow:

• 5개 브랜치: main, develop, feature, release, hotfix
• 체계적 릴리스 관리
• 큰 프로젝트에 적합

2. GitHub Flow:

• 2개 브랜치: main, feature
• 단순하고 빠른 배포
• 웹 서비스에 적합

3. 선택 기준:

Git Flow:
- 정해진 릴리스 주기
- 여러 버전 유지보수
- 엄격한 품질 관리

GitHub Flow:
- 지속적 배포
- 빠른 반복 개발
- 단일 프로덕션 버전

Phase 5 완료! 🎉

배운 것:

• Day 41-45: 브랜치 기초
• Day 46-47: Fast-Forward & 3-Way Merge
• Day 48: Merge Conflict
• Day 49: Rebase
• Day 50: 브랜치 전략

다음 Phase: Day 51부터 협업 (Fork, Pull Request)을 배웁니다!

완료 체크:

• Git Flow의 브랜치 구조를 안다
• GitHub Flow를 이해했다
• 프로젝트에 맞는 전략을 선택할 수 있다

Week 10 완료! 🎉

---

← Day 49

전체 커리큘럼

Day 51 →