단북
프론트엔드 기술 면접·실무 프로젝트 지식

깃플로는 무엇이며, 그 외 버전 관리 전략은 무엇이 있나요?

Git Flow의 브랜치 구조와 GitHub Flow·Trunk-Based 등 대표적인 브랜치 전략을 비교해 정리합니다.

브랜치 전략(branching strategy) 은 팀이 Git 브랜치를 어떻게 나누고 합칠지에 대한 약속입니다. Git Flow 는 그중 정형화된 대표 전략입니다.

Git Flow

Vincent Driessen이 제안한 모델로, 역할이 정해진 여러 브랜치를 사용합니다.

  • main(master) — 배포된 안정 버전. 태그로 릴리스 표시.
  • develop — 다음 릴리스를 위한 통합 브랜치.
  • feature/* — 기능 개발. develop에서 분기 → develop으로 병합.
  • release/* — 출시 준비(버그 수정·버전). develop에서 분기 → main·develop으로 병합.
  • hotfix/* — 운영 긴급 수정. main에서 분기 → main·develop으로 병합.

체계적이고 릴리스 주기가 뚜렷한 제품(버전·릴리스 관리가 중요한 경우)에 적합하지만, 브랜치가 많아 복잡하고 무겁다는 단점이 있어 CD(지속적 배포) 환경에는 과한 경우가 많습니다.

그 외 전략

  • GitHub Flowmain 하나를 중심으로, 작업은 짧은 수명의 브랜치에서 하고 PR로 리뷰 후 main에 병합 → 바로 배포. 단순하고 지속 배포에 적합.
  • GitLab Flow — GitHub Flow에 production·환경(staging 등) 브랜치를 더해, 배포 환경과 브랜치를 연계.
  • Trunk-Based Development — 모두가 하나의 트렁크(main)에 작은 단위로 자주 병합. 장수 브랜치를 피하고, 미완성 기능은 피처 플래그로 숨김. CI/CD·대규모 팀에서 선호.
전략브랜치 수배포 주기적합한 경우
Git Flow많음정해진 릴리스버전·릴리스 관리 중요
GitHub Flow적음수시(지속)웹 서비스, 빠른 배포
Trunk-Based최소매우 잦음(CD)CI/CD, 대규모·고빈도

정답은 없으며, 팀 규모·릴리스 주기·CI/CD 성숙도에 맞춰 선택합니다.

브랜치 전략에 대한 설명으로 옳은 것은?

이 레슨을 다 읽으셨나요?

완료 표시는 이 브라우저에 저장됩니다.