Workflow 선택은 나머지 규칙을 결정해
Workflow라는 말은 부드럽지만 branch 수명, release 주기, conflict 빈도, CI 구조까지 결정해. 대표 pattern 셋은 서로 다른 팀에 맞아. 가장 나쁜 선택은 뒤섞는 거야. 절반은 GitFlow, 절반은 trunk-based처럼 행동하면 main에 양립하기 어려운 두 모양의 commit이 들어와. 하나를 고르고 문서화한 뒤 플랫폼 설정으로 강제해.
GitHub Flow가 가장 단순해. main은 언제나 배포할 수 있고, 모든 변경은 main에서 갈라진 짧은 feature branch에서 만들어 PR, review, merge 또는 rebase를 거쳐 land하고 배포해. 오래 사는 develop이나 release branch는 없어. 현대 web과 SaaS처럼 연속 배포하는 팀에 맞고 branch에서 배포까지 몇 시간 안에 끝나. 단, CI/CD가 실제로 작동해야 'main은 배포 가능하다'는 약속이 참이 돼.
Trunk-Based Development는 더 나아가 대부분의 엔지니어가 main에 직접 commit하거나 몇 시간짜리 PR만 써. feature branch는 드물고 미완성 기능은 feature flag 뒤에 숨겨 하루에도 여러 번 release해. 빠른 feedback에 최적화된 팀이 쓰며 강한 feature flag, 넓은 test, main이 깨지면 모든 일을 멈추고 몇 분 안에 고친다는 문화가 필요해.
GitFlow는 가장 무거워. main은 운영 release만 담고 develop이 통합 branch가 돼. feature는 develop에서 갈라지고 release branch에서 tagged release를 안정화하며, hotfix는 main에서 바로 갈라져 main과 develop 양쪽으로 돌아가. desktop app, semver library, 규제 software처럼 versioned product를 ship하는 팀에 맞아. 재현 가능한 release line을 얻는 대신 복잡성을 치르므로 연속 배포에는 어울리지 않아.