Git Flow vs GitHub Flow, 그리고 다른 전략들

왜 두 전략이 따로 생겼을까

2010년대 초의 소프트웨어는 정해진 주기로 배포됐고, 큰 업데이트 전에는 상당한 준비 기간이 필요했습니다. 이 시절 CI는 초기 단계였고 CD(지속적 배포)는 대중화되기 전이었죠. 그래서 master, develop을 중심에 두고 feature, release, hotfix 브랜치로 세분화한 복잡한 모델, Git Flow가 등장했습니다. 주기적인 릴리즈와 갑작스런 핫픽스를 체계적으로 관리하기 위한 도구였습니다.

시간이 지나 CI/CD가 발전하면서 배포 빈도가 극적으로 빨라졌습니다(하루에 여러 번 배포하는 회사도 생겼죠). 이런 환경에는 복잡한 브랜칭보다 간결한 모델이 필요해졌고, 그렇게 main + feature 브랜치만 쓰는 GitHub Flow가 주목받게 됩니다.

비교

	GitHub Flow	Git Flow
브랜치 구조	main + feature	master, develop, feature, release, hotfix
좋은 상황	간단하고 빠른 개발, 항상 최신 버전 공개	여러 버전 동시 관리, 복잡하고 체계적인 관리 필요
대표 예시	자주 업데이트하는 웹 서비스	과거 버전 지원이 필요한 라이브러리, 여러 회사 대상 B2B 소프트웨어

GitLab Flow: 두 전략의 절충안

GitLab Flow는 GitHub Flow와 Git Flow의 장점을 섞어 CI/CD 환경에 최적화한 전략입니다. main, feature 외에 environment 브랜치를 추가로 씁니다. 실제 서비스가 도는 production, 개발 중인 develop뿐 아니라 QA·stage 같은 추가 환경까지 각각 브랜치로 나누고, 해당 브랜치에 머지되면 그 환경으로 즉시 배포되도록 CI/CD 파이프라인을 구성합니다. 배포 시나리오가 다양한 팀에 유리하지만, 브랜치 종류가 많은 만큼 초기 학습 비용과 동기화 관리 부담이 있습니다.

Trunk Based Development: 극단적으로 빠른 통합

main(trunk) 브랜치 하나에 거의 모든 작업을 즉시 합치는 전략입니다. GitHub Flow와 비슷하지만 PR 주기가 훨씬 짧아서, 사용자가 눈치채기 힘든 작은 단위까지 바로 main에 머지합니다.

아직 완성되지 않은 기능을 어떻게 배포 가능한 main에 얹을 수 있을까요? 바로 feature toggle입니다. 기능을 코드로는 합쳐두되 사용자에게는 노출하지 않도록 켜고 끌 수 있게 만드는 방식이죠. 덕분에 지속적 통합의 이점을 누리면서도 미완성 기능을 숨길 수 있습니다. 자주 커밋하고 자주 테스트해야 한다는 부담이 있지만, 코드베이스가 크게 벌어지는 걸 막고 배포 리스크를 낮춰줍니다.

출처: Codyssey-B1/B2-2