GitHub Flow 도입 전 고려해야 할 것들

브랜치 전략이란 여러 개발자가 하나의 저장소를 사용하는 환경에서 저장소를 효과적으로 활용하기 위한 워크플로우이다.

프로젝트를 킥오프할 때면, 매번 고민되는 것이 브랜치 전략이다.

작년 퇴사몬 프로젝트에서는 설계 단계에서 GitHub Flow 전략을 고려했다.
브랜치 전략 도입에 앞서 GitHub Flow 이외에도 Git Flow, GitLab Flow, TBD 등에 대해 알아보며 다각도에서 고려했지만, 다음과 같은 이유로 최종적으로 GitHub Flow가 적절할 것이라는 결론에 도달했다.

1. 별도의 정형화된 배포 주기가 없었고,
2. 소규모(2인) → 충돌, 컨텍스트 꼬임이 발생할 가능성이 낮았으며,
3. 장기간 유지되는 프로젝트가 아니며, 버저닝이 필요한 애플리케이션이 아니다.

또한, Prography 활동 기간 동안 주요 개발이 집중적으로 이루어지고, 서비스 유지 기간이나 향후 버전 관리 계획이 명확하지 않았던 점까지 고려했을 때, 비교적 간결하고 상시 배포에 적합한 GitHub Flow는 우리 팀에 가장 현실적이라고 판단하게 되었다.

하지만, 기획이 구체화되며 1차적으로 MVP를 빠르게 출시하고, 2차적으로는 정식 배포를 계획하게 되었으며, 이 사이에 QA/QC 단계를 거치는 흐름이 포함되면서, 단계적으로 완성도를 높이고 흐름을 분리해 관리할 수 있는 Git Flow 브랜치 전략을 따르게 되었다.

아래 내용은 GitHub Flow 전략을 채택하기 전 고려해야 할 사항들과, 유사한 프로세스에서 GitHub Flow가 지닐 수 있는 한계점에 대해 함께 돌아보며 공유하고자 한다.