[Git] Git-flow main 배포 시 혼란스러웠던 부분 정리

놀토에서는 브랜치 전략으로 git-flow를 사용하고 있는데 메인 서비스용 서버(product server)에 배포시 가끔 혼란이 와서 문서화의 필요성을 느꼈습니다.

우선 놀토의 브랜치의 종류는 다음과 같습니다.

평소에 main 브랜치에 머지하기 위한 과정은 다음과 같았습니다.

develop 브랜치로부터 release 브랜치를 생성한다.
release 브랜치에서 버전 tag를 생성하고 main 브랜치에 머지합니다. (이때 버전 tag는 develop 브랜치에도 머지해줘야 합니다.)
main 브랜치에서 QA를 진행하고 버그는 develop 브랜치에서 bug-fix 브랜치를 생성합니다.
버그 수정이 완료되면 develop 브랜치에서 main 브랜치로 merge 시킵니다.

현재 release 브랜치를 적극적으로 사용하지 않고 진행하는 데는 몇가지 이유가 있습니다.

물론 main 에 배포를 한 상태에서 QA를 진행하는 것은 문제가 있다고 생각됩니다.

현재는 작업하는 인원이 많은것도 아니며 QA를 거창하게 진행하기엔 필요없는 리소스가 발생한다고 생각합니다.

따라서 QA는 develop 브랜치와 서버에서 충분히 진행하고 main 브랜치에 머지하도록 합니다.

그럼 git 명령어를 명시하면서 위의 과정을 정리해보겠습니다.

저장소 이름
upstream : 최신의 소스코드가 저장되는 저장소
origin : 개인이 upstream 저장소를 fork 한 저장소
local : 개인 로컬에 있는 저장소

우선 로컬의 develop 브랜치에서 시작합니다.

$(develop) > git pull --rebase upstream develop

$(develop) > git checkout -b release-0.0.0v

$(release-0.0.0v) > git tag [태그이름]

$(release-0.0.0v) > git checkout develop

$(develop) > git merge --no-ff release-0.0.0v

$(develop) > git push upstream develop

$(release-0.0.0v) > git checkout main

$(main) > git merge --no-ff release-0.0.0v

$(main) > git push upstream main

여기서 upstream에 직접 push하는 방법과 release 브랜치를 upstream에 올려서 pr 생성 후 merge 하는 방법도 있습니다.

git-flow 전략을 진행하면서 한가지 헷갈렸던 부분을 말씀드리면

입니다.

답은 아니라고 생각합니다.

두 브랜치의 commit 이력 상태를 완벽하게 일치시킨다는 것은 굉장히 어렵고 번거로운 작업이 될것입니다. 그래서 코드를 같게 유지하는 것이지 커밋 이력까지 같게하는것은 현재는 힘들다 라고 생각합니다.

기록기록