Git Flow / GitHub Flow

Git Flow / GitHub Flow

브랜치 전략 = 팀이 합의한 브랜치 사용 규칙. 팀으로 개발할 때 충돌과 혼란을 막기 위해 필요하다.

---

Git Flow

규모가 크고 배포 주기가 긴 프로젝트에 적합.

main        ─────────────────────────────── (실제 운영 서버)
               ↑ merge          ↑ merge
release     ──────────        ──────────    (배포 준비, QA)
               ↑ merge
develop     ──────────────────────────────  (개발 통합 브랜치)
              ↑         ↑
feature/login  feature/payment              (기능 개발)

브랜치	역할
main	운영 서버와 동일한 코드
develop	다음 배포를 위한 통합 브랜치
feature/*	기능 개발 (develop에서 분기, develop으로 머지)
release/*	배포 전 QA, 버그픽스
hotfix/*	운영 긴급 수정 (main에서 분기, main+develop 둘 다 머지)

흐름:

1. develop에서 feature/login 분기
2. 기능 개발 완료 → develop으로 PR & 머지
3. 배포 시점에 develop → release/1.0 분기
4. QA 완료 → release/1.0 → main 머지 + 태그

---

GitHub Flow

규모가 작고 배포 주기가 짧은 프로젝트에 적합. 더 단순하다.

main        ──────────────────────────────  (항상 배포 가능한 상태)
              ↑ PR & merge   ↑ PR & merge
feature/login   feature/payment

브랜치	역할
main	항상 배포 가능한 상태 유지
feature/*	기능 개발, 버그픽스 등 모든 작업

흐름:

1. main에서 feature/login 분기
2. 개발 완료 → main으로 PR
3. 코드 리뷰 → 승인 → 머지
4. 머지되는 순간 자동 배포 (CI/CD)

---

어느 걸 쓸까

Git Flow:    앱 배포, 분기별 릴리즈, QA 기간이 있는 팀
GitHub Flow: 웹 서비스, 매일 배포, 빠른 이터레이션

실무에서는 GitHub Flow를 단순화해서 쓰는 곳이 많아졌다.