새로 사이드 프로젝트를 시작하면서 브랜치 전략에 대해 이야기 했고, github-flow와 git-flow 둘 중 고민하게 되었다.
이 중 최종적으로 git-flow를 선택한 이유에 대해서 정리해 보고자 한다.
[안드로이드 프로젝트를 하는 입장에서 고려를 하였고, 더 좋은 방안이 있을 수 있습니다.]
먼저 github-flow와 git-flow의 각 특징을 짚어보고 우리는 왜 git-flow를 선택헀는지 기록하고자 한다.
github-flow
위 이미지와 같이 main 브랜치에서 feature, hotfix, bugfix 등 브랜치를 파생시켜서 작업을 하고 다시 main 브랜치로 merge하는 방식이다.
git-flow에 비해 복잡성이 없다는 것이 가장 큰 장점이다.
하지만 우리가 앱을 출시하고, 유지보수를 하게 되었을 때의 여러 문제점을 제시하였을 때 git-flow 브랜치 전략이 적절해 보였다.
어떤 문제점이 있을까. 예시 시나리오를 들어보겠다.
첫 번째 문제
현재 1.0.0을 출시하여 운영 중이고, 1.0.1을 개발 중이다.
- 이 때 개발 완료된 브랜치를 main에 merge하면 실 서비스에 변경이 생긴다.
- 실 서비스는 앱으로 배포가 되어 있으니 문제가 없는 것 아닌가?
- hotfix가 일어나면?
- feature 개발을 완료했지만 merge를 안하고 그대로 두는 것은 어떤가?
- 개발 완료된 기능으로 다음 기능 개발이 순차적으로 이어져야 할 때 고민거리가 생긴다. (ex) 파생 브랜치 생성을 할 것인가?)
- 출시시에 충돌해결로 많은 애를 먹을 수 있겠다.
위 시나리오를 검토했을 때 현재 개발이 완료된 브랜치가 필요하다고 판단했고. 우리는 이를 git-flow의 develop 브랜치로 정의했다.
두 번째 문제
현재 1.0.0을 출시하여 운영 중이고, 1.0.1을 개발 완료 단계에 있어 QA후 플레이스토어 검토를 받으려고 한다. 또한 1.0.2를 개발 중이다.
- 1.0.1은 어떤 브랜치에서 정의해야 하는가?
위 시나리오를 고려했을 때 release 브랜치를 고려할 수 있겠다. 하지만 사이드 프로젝트 규모에서 QA는 develop 브랜치에서 충분히 일어날 것 같고, 플레이 스토어 배포단계에서 거절을 당하는 경우 정도로 쓸 수 있다. 정식 QA단계 또는 팀이 있는 것이 아니면 release는 선택사항이라고 생각한다.
git-flow
이제 git-flow가 왜 이렇게 구성되는지 보이시나요?
결론
기존 팀원 모두 이해하기 쉬운 github-flow로 선 고려를 하였고, develop, release 브랜치에 대해서 필요성을 느꼈더니, git-flow가 되었다. 정확히 release는 염두에만 두고 있기로 하여서, git-flow를 살짝 변형한 전략에 가깝다고 볼 수 있겠다.
