전략 이름과 그림만 외웠는지, 우리 팀 상황에서 무엇을 고를지 트레이드오프를 묶어 설명할 수 있는지를 가른다.
Git Flow는 develop·release·hotfix 같은 다중 장수 브랜치로 릴리즈 단계를 명시적으로 가른다. GitHub Flow는 main에 짧은 수명의 feature 브랜치를 붙였다가 PR로 빠르게 병합·배포하는 단순한 모델이다. Trunk-Based Development는 더 나아가 짧은 브랜치 또는 직접 trunk 커밋으로 통합 빈도를 최대화하고, 기능 노출은 피처 플래그로 끊는다. 선택은 "무엇이 옳다"가 아니라 우리 팀의 배포 빈도·QA 게이트·CI 자동화가 어떤 모델을 받쳐줄 수 있느냐로 갈린다.
릴리즈 브랜치가 묵으면서 병합 충돌이 폭주한 경험이 있다면 트렁크 기반 전환 논의와 자연스럽게 연결할 수 있다
QA 사이클이 길어 PR이 정체된 경험이 있다면 피처 플래그·다크 런치 도입 이야기로 이을 수 있다
핫픽스가 main과 release 사이에서 꼬여본 적이 있다면 브랜치 모델 단순화 결정의 근거로 풀 수 있다
CI 안정성이 부족해 트렁크 기반으로 못 갔던 경험이 있다면 자동화 선후 관계 이야기로 연결할 수 있다
아직 공개된 답변이 없어요. 첫 공개 답변을 남겨보세요.