Git Flow / Github Flow

Git Flow vs Github Flow

• Github Flow와 Git Flow는 각각 Git을 활용한 워크플로우(브랜치 전략)이다.
• 두 방법은 팀의 개발 방식, 배포 주기, 프로젝트의 복잡도 등에 따라 선택될 수 있다.

Github Flow

간단하고 경량화된 워크플로우

• 주요 브랜치 : main (또는 master) 브랜치 하나를 기준으로 운영
• 작업 방식 : 새로운 기능이나 버그 수정 시, main에서 파생된 feature, branch를 만들어 작업 후 Pull Request(PR)를 통해 리뷰하고, 문제가 없으면 main브랜치에 merge한다.
• 배포 : PR이 merge되면 즉시 배포하는 형태가 일반적이다. 지속적 통합(Continuous Intergration)과 지속적 배포(Continouse Deployment)환경에 적합하다.

유연성과 속도

• 코드 리뷰 중심 : PR을 통해 코드 리뷰와 토론이 이루어지며, 빠른 피드백과 반영이 가능하다.
• 짧은 개발 사이크 : 기능 개발 및 배포가 빠르게 이루어져, 빈번한 릴리즈와 릴리즈 자동화에 적합하다.

Git Flow

체계적이고 복잡한 브랜치 구조

• 주요 브랜치 : master(또는 main)와 develop브랜치를 기본으로 사용한다.
  • develop: 다음 릴리즈를 위한 통합 브랜치
  • master: 프로덕션 배포 버전 관리
• 보조 브랜치 :
  • feature: 새로운 기능 개발 시 develop에서 분기하여 작업
  • release: 릴리즈 준비 단계에서 develop 브랜치로부터 분기하여 버그 수정 및 최종 테스트 후 master와 develop에 병합.
  • hotfix: 프로덕션 환경에서 긴급한 버그 수정을 위해 master에서 직접 분기하여 작업 후 develop에도 병합.

버전 관리와 릴리즈 사이클 중심

• 명확한 버전 관리 : 각 릴리즈와 핫픽스에 대해 명확한 브랜치 전략을 통해 안정적인 배포를 도모한다.
• 긴 개발 사이클 : 기능 개발 후 여러 단계를 거쳐 릴리즈하는 형태로, 릴리즈 주기가 상대적으로 길다.