이전 글에서는 고객사 사이트 소스에 대한 브랜치 전략을 다뤘다면, 이번에는 제품 개발에 대한 브랜치 전략을 이야기해볼까 합니다. 🚀
SVN 시절: 브랜치 전략? 그게 뭔데 먹는 건가요? 🤔
SVN을 사용할 때는 릴리즈라는 개념 자체를 경험하지 못했습니다.
- 버그 패치나 새로운 기능이 추가될 때? 그냥 바로 commit! 끝.
- SVN에서도 브랜치를 만들 수 있었지만(폴더 복사 방식) 딱히 사용하진 않았어요.
그러다가 GitHub을 도입하고 릴리즈를 처음 경험하게 되었고, 고객사 사이트를 GitHub에서 관리하면서 제품 개발에서는 브랜치 전략이 정말 중요하겠구나를 깨달았습니다.
첫 번째 릴리즈: 그래도 순탄했던 시작
처음에는 따로 브랜치 전략을 가져가지 않았어요. 기존 고객사 사이트에서 사용하던 방식을 그대로 가져왔습니다.
- main과 develop 브랜치를 생성
- 릴리즈를 위해 develop에서 release 브랜치 생성
- 각 작업(Task)별 브랜치를 release 브랜치에서 파생시켜 개발 진행
- 모든 Task가 release 브랜치에 merge되면, develop 브랜치로 merge
- develop에 CI/CD가 설정되어 있어서 테스트를 위해 merge!
- 테스트 완료 후, develop → main merge & Tagging & Release!!
✅ 첫 번째 릴리즈는 예상보다 순조롭게 끝났습니다.
두 번째 릴리즈: 고난의 시작...
첫 번째 릴리즈 방식이 괜찮아 보여서 동일한 전략을 유지했습니다.
그런데…
첫 번째 문제: develop의 기존 commit 내역이 PR에 포함됨
릴리즈 PR을 생성했는데, 첫 번째 릴리즈 때 develop에 쌓였던 commit 내역들이 모조리 따라온 것…!
열어보기 무서운 Files changed… 🤪
두 번째 문제: Merge Conflict 폭탄💥
main 브랜치에서 GitHub Action을 위해 .github 폴더를 직접 수정한 게 화근이었습니다.
develop 브랜치에는 해당 변경 사항이 없었고, 이를 merge하는 과정에서 충돌이 발생…!
- main 브랜치는 강제 merge가 불가능 했지만, GitHub Action을 위해 잠시 해제하고 작업했던 것 으로 보입니다.
해결 방법 🛠️
1️⃣ conflict 해결: main과 develop을 동기화
merge conflict를 해결하기 위해 main과 develop 브랜치를 맞춰주는 작업이 필요했습니다.
- main에서 새로운 브랜치 생성
fix/conflict→ develop과 merge - 이 과정에서 conflict 발생! 하지만 여기서 해결한 후 develop에 merge
- 이제 develop이 main과 동기화됨
- main으로 다시 merge하면 conflict 없이 정상적으로 반영 가능!
2️⃣ 새로운 브랜치 전략 수립: Git Flow 도입
위 문제를 근본적으로 방지하기 위해, 전체적인 제품 개발 릴리즈 브랜치 전략을 재정립했습니다.
서칭 끝에, Git Flow 브랜치 전략이 우리 팀에 적합하다고 판단했어요.
👉 Git Flow 브랜치 전략을 채택한 이유:
- 수시 배포가 필요하지 않음 (Release 주기가 명확)
- 여러 명이 협업하여 릴리즈 진행 (혼자가 아님!)
- 충분한 테스트 기간이 필요함
그래서 제품 개발 온보딩 문서에도 Git Flow 브랜치 정책을 추가했고, 팀원들이 쉽게 따라갈 수 있도록 가이드를 마련했습니다! 🚀
마무리
처음에는 SVN에서 브랜치 전략 없이 개발하다가, GitHub으로 넘어오면서 릴리즈 브랜치 관리의 중요성을 깨닫게 되었습니다.
첫 번째 릴리즈는 무난했지만, 두 번째 릴리즈에서 커밋 내역 누적과 Merge Conflict라는 현실적인 문제를 마주하면서 브랜치 전략의 필요성을 체감했죠.
Git Flow 브랜치 전략 도입을 통해 릴리즈 프로세스를 최적화했고, 다음 릴리즈에서 얼마나 수월하게 진행할 수 있을지 기대가 됩니다!!🎉
다음에는 이번 브랜치 전략을 어떻게 적용했는지 회고할 수 있는 글이 되겠네요!
