핏펫몰 개발 스쿼드의 git 전략 연대기

핏펫몰 개발 스쿼드가 GitHub Flow 비슷한 무규칙 상태에서 Git Flow 를 도입하고, 두 차례 수정을 거쳐 다시 브랜치를 걷어내기까지의 변천사다. 각 단계에서 무엇이 불편했는지를 구체적인 상황으로 적어 두어, 왜 그 전략이 그 팀에 안 맞았는지가 드러난다.

핵심 포인트

초기에는 개발자가 적고 일정이 촉박해 완료되면 바로 기본 브랜치에 병합하고 알파·스테이징에 수시 배포했다. GitHub Flow 에 가까운 형태였다.
서비스 오픈 후 GitHub Flow 와 Git Flow 를 비교해 Git Flow 를 택했다. 알파·스테이징 테스트 흐름에 맞고 테스트를 통과한 브랜치만 병합할 수 있어서였다.
Git Flow 의 단점 ①: feature 브랜치를 develop 에서 따고 개발 직후 develop 에 병합하니, 나중에 딴 feature2 가 feature1 의 변경 내역을 통째로 안고 간다.
Git Flow 의 단점 ②: 여러 feature 가 하나의 release 로 묶여 올라가므로 한 건이라도 QA 를 통과 못 하면 배포 전체가 밀린다.
최종적으로 develop 을 없애고 main 을 언제든 배포 가능한 상태로 유지하며, feature 단위로 알파→스테이징→상용을 거치는 형태로 정착했다.

상세 정리

Git Flow 채택 시 브랜치 구성: 상용 배포용, 기본, 스테이징 배포용(QA), Release Candidate, 알파 배포용(개발자 내부 테스트), 개발 브랜치로 나뉘어 있었다.
단점 ① 의 결과: feature1 이 버그나 일정으로 밀리면 feature2 는 손으로 feature1 내역을 제거하거나(나중에 병합 충돌 발생) feature1 배포까지 기다려야 했다.
1차 수정: feature 브랜치를 develop 이 아닌 다른 지점에서 따도록 바꿔 단점 ① 을 없앴다. 하지만 릴리즈 병합으로 인한 배포 지연은 그대로였다.
2차 수정: Release Candidate 브랜치를 없애고 `releases/<배포날짜>` 형태로 날짜를 분리해 단점 ② 를 해결했다.
새로 생긴 문제: 배포를 주 1회 하다 보니 배포 사이즈가 커져 담당자의 배포 스트레스가 커졌고, 배포 후 정상 동작 확인에 시간이 많이 들어 배포일에는 다른 작업을 거의 못 했다.
연관 부서 입장에서는 하루 만에 끝난 작업도 최대 일주일 지연되는 일이 생겼다.
결정적 자각: develop 이 사실상 기본 브랜치와 차이가 없고, 날짜로 브랜치 이름을 정하면 배포가 밀리는 순간 이름이 안 맞는다는 것이었다.
현재 구성: 상용 배포 브랜치, 언제든 배포 가능한 기본 브랜치(develop 역할 겸함), 스테이징 배포 브랜치, 알파 배포 브랜치 넷으로 간략화했다.
현재 흐름: 기본 브랜치에서 feature 를 따고 알파에 PR·병합해 내부 테스트, 스테이징에 PR·병합해 QA, 그다음 기본 브랜치와 상용 순으로 올린다. feature 별 개별 테스트와 배포가 가능해졌다.
수시 배포의 부작용: 병합되는 대로 배포하니 관리자가 하루 종일 PR 검토와 배포만 하게 되는 일이 벌어져, 각 개발자가 자기 브랜치를 책임지고 관리하도록 바꿨다.
남은 과제: 상용 배포 후 알파 서버 브랜치를 손으로 맞춰야 하는 문제가 있어 GitHub Actions 로 자동화할 예정이다.
결론: 단점 없는 Git 전략은 없으며 인원이 더 늘면 새로운 단점이 부각될 테니 그때 다시 바꾸겠다고 정리한다.