현재 사용하고 있는 방식은 gitlab flow를 차용하면서도 저희 프로젝트 특성에 맞게 feature, develop, main 3개의 브랜치만을 사용하고 있었습니다. 하지만, 앱 버전 관리라는 이슈와 함께 hotfix가 필요했고 이에 gitflow의 develop에서 release를 branch로 따는 방식을 차용하려 합니다.
전체적인 구조는 아래 그림과 같습니다.
develop과 feature branch
develop에서 feature branch를 따고, squash and merge로 PR을 머지하는 방식은 같습니다.
release branch
develop에서 스프린트 주기마다 main으로 PR을 보내는 것이 아닌 출시에 맞추어 release branch에 Tag와 함께 Merge하는 방식/새로운 브랜치를 만드는 방식입니다.
hotfix branch
hotfix는 release 브랜치에서 파생하여 bug를 고친 뒤 release, develop branch에 squash and merge(PR)을 합니다. 그 뒤, 문제가 해결되었으므로 해당 branch는 삭제합니다.
이 경우 가질 수 있는 장점은 문제였던 버전 관리와 hotfix 문제가 해결된다는 것입니다.
단점은 기존의 방식보다 조금 더 복잡해진다는 것입니다.
gitflow 방식보다 덜 복잡하지만 gitlab flow보다는 더 복잡하다. 팀원들의 의견에 맞추어 girflow 방식을 채택하기로 했다.
hotfix branch를 release, develop branch로 합칠 때 아래와 같은 부분들을 고민했다.
그래서 타협한 것은 hotfix branch에서 squash and merge를 각 release, develop branch로 하는 것이다. develop에서 release로 새로운 버전 업데이트를 할 때 같은 내용이 다른 커밋으로 중복이 되겠지만 커밋내역이 더러워져 트래킹이 어려워지는 것보다는 괜찮다고 생각되었다.
feature와 develop은 기존의 방식을 유지하기 때문에 자세히 적지 않겠습니다.
git checkout develop
git checkout -b {JIRA Ticket} // git checkout -b TW-124
...add and commit...
git pull --rebase origin develop
(if there is conflict, solve and add again)
git push origin {JIRA Ticket}
새로운 버전이 준비가 되었을 때 develop에서 release 브랜치로 머지합니다.
(release branch가 이미 존재할 때를 가정)
develop -> release PR 보내기
squash and merge
relase에서 bug가 발생해 hotfix를 만들 때입니다.
git checkout release
git checkout -b hotfix
...add and commit...
git push origin hotfix
hotfix -> release PR 보내기(squash and merge)
hotfix -> develop PR 보내기(squash and merge)
이상입니다.