Git branch 전략 정하기

기존 방식(gitlab)과 새로운 방식(gitflow)

현재 사용하고 있는 방식은 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에 대한 고민

hotfix branch를 release, develop branch로 합칠 때 아래와 같은 부분들을 고민했다.

• 깔끔한 commit 내역을 유지하고 싶다(squash and merge)
  - squash and merge의 문제는 체크섬이 새로 생기기 때문에 release의 hotfix merge 체크섬과 develop의 hotfix merge 체크섬이 다르다는 것이다. 즉, 같은 내용이지만 다른 커밋으로 git은 인지한다는 점
• release, develop에 각각 머지해도 이후 develop에서 release로 머지할 때 같은 내역임을 git이 인지했으면 좋겠다(create a merge)
  - 문제는 commit 내역이 복잡해지고 더러워질 수 있다
• cherry pick을 이용하면 hotfix -> release (squash and merge), release -> develop (cherry-pick) 와 같이 될 수 있다.
  - 문제는 branch와의 머지를 통해 파악할 수 있는 트래킹과 PR 리뷰와 같은 것들을 시용할 수 없다는 점이다. 별로 쿨해 보이지 않는다.

그래서 타협한 것은 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)

이상입니다.