브랜치 전략에 대한 고민

새로운 프로젝트를 시작하며 가장 먼저 생긴 고민이 있었습니다.

어떤 Branch 전략을 쓸까?

지금까지 해왔던 프로젝트에서는 항상 Git Flow를 사용해왔습니다.
큰 이유는 없었고, 다들 사용하고, 국룰처럼 여겨지기에 별 고민없이 사용했습니다.

하지만 사이드 프로젝트 규모에서는 항상
feature, develop, main 브랜치만 사용하고 hotfix, release 브랜치등은 사용하는 일이 거의 없었습니다.

프로젝트 규모에 비해 브랜치 전략이 과하다는 생각이 들었고, 브랜치 전략에 대해 조금 더 알아보고, 프로젝트 규모에 맞는 브랜치 전략을 선택하기로 했습니다.

후보 1) Git Flow

가장 유명하고, 가장 많이 쓰는 전략입니다.
이번 포스팅의 주제는 아니기 때문에 간단하게만 알아보겠습니다.

브랜치 종류

1. main (배포 브랜치)
   실제 배포되는 브랜치로, 안정적인 코드만 있는 브랜치.
2. develop (개발 브랜치)
   여러 기능 브랜치(feature/*)가 병합되며 개발이 이루어지는 브랜치.
3. feature/* (기능 개발 브랜치)
   새로운 기능을 개발하는 브랜치
4. release/* (배포 준비 브랜치)
   배포 전 테스트 및 버그 수정을 진행하는 브랜치
5. hotfix/* (긴급 수정 브랜치)
   버그를 수정하기 위한 브랜치

상황별 브랜치 흐름

기능 개발

1. develop에서 feature/* 브랜치를 만듭니다.
2. feature 브랜치에서 작업 후 develop 브랜치로 병합합니다.

배포

1. develop 브랜치에서 release 브랜치를 만듭니다.
2. release 브랜치에서 QA 및 버그를 수정합니다.
3. 테스트가 끝나면, release 브랜치를 main 브랜치로 병합하여 배포합니다.
   이때, 변경사항들이 develop에도 반영되어야 하므로 develop에도 병합합니다.

버그 수정

배포 환경에서 버그가 발견되어 긴급한 수정이 필요할때 사용하는 방법입니다.

1. main 브랜치에서 hotfix/* 브랜치를 생성합니다.
2. hotfix 브랜치에서 버그를 수정하고, 이를 main 브랜치에 바로 병합하고 재배포합니다.
3. 변경사항들이 develop에도 반영되어야 하므로 develop에도 병합합니다.
   만약 진행중인 release 브랜치가 있다면 release에도 병합합니다.

---

브랜치 종류도 다양하고 사용 방법도 꽤나 복잡합니다.

그만큼 체계적으로 관리되므로 규모가 큰 프로젝트나 여러 명이 협업하는 환경에서는 유용하지만,
위에서 말했던 것 처럼 이전에 진행했던 프로젝트에는 release, hotfix 브랜치 등은 잘 사용하지 않았고 조금 과한 브랜치 전략이라는 생각이 들었습니다.

이번에 진행할 프로젝트도 FE가 최대 2명으로 진행될 예정이었기 때문에, 조금 더 적합한 다른 방안을 찾아보기로 했습니다.

후보 2) Github Flow

Github Flow는 Github를 이용하는 간단한 워크플로우로, Git Flow에 비해 정말 간단한 구조를 갖고 있습니다.

Github Flow의 경우 main(사진의 master) 브랜치와, feature 브랜치 2종류의 브랜치만 사용합니다.

이 방식은 Git flow의 release/hotfix 브랜치에서 진행하는 작업을 모두 feature 브랜치에서 진행하고 main 브랜치에 병합하여 배포하는 전략입니다.

단순하고 빠른 배포가 가능하여 작은 규모의 프로젝트에 적합한 방식이긴 하지만,
main으로 병합되는 PR의 코드리뷰를 꼼꼼히 하지않으면, 오류가 곧바로 배포된다는 문제가 있고, QA 를 진행할 브랜치(git flow의 Release 브랜치)가 없다는 단점이 있습니다.

---

현재 나의 상황

이전 프로젝트를 생각해봤을때, 코드리뷰를 열심히 한다고 해도 오류를 완벽하게 잡지 못하고 머지되는 경우도 많았고,
무엇보다 이번 프로젝트의 기획 측에서 QA를 진행할 수 있는 개발 환경이 있었으면 좋겠다는 요청이 있었습니다.
(이를 위해 API 서버도 production, development로 분리되어 있는 상황이었습니다.)

따라서, 오류가 쉽게 배포될 수 있고 배포 테스트를 위한 브랜치가 없는 Github Flow 도 적합하지 않다고 생각을 했습니다.

그래서 특정 브랜치 전략을 그대로 따르지 않고, Git Flow와 Github Flow를 적절히 섞어서 현재 내 프로젝트에 적합한 방식을 만들어야 하나를 고민하던 때에, GitLab Flow에 대해 알게되었습니다.

후보 3) GitLab Flow

GitLab의 문서에는 다음과 같이 써있습니다.

GitLab Flow는 GitFlow 보다 더 간단한 대안이며
...
GitLab Flow는 main브랜치와 바로 작동합니다.
...
팀은 필요에 따라 사전 프로덕션 브랜치를 추가할 수 있습니다. 예를 들어, from main to test, from test to acceptance, from acceptance to production.

chrome 번역을 이용하여 표현이 살짝 어색하지만, 요약하자면

• feature 브랜치들이 develop이 아닌 main 브랜치로 바로 병합되고,
• main이 production으로 병합되어 배포가 이루어지고,
• main 과 production 사이에 필요에 따라 브랜치를 추가할 수 있다.

즉

• release/hotfix 등의 여러 단계를 거쳐야하는 git flow 보단 간단하고
• 기능들이 바로 배포되는 Github flow 보단 안전하며
• QA를 위한 테스트용 브랜치를 운영할 수 있는

제 상황에 딱 맞는 전략이라고 할 수 있었습니다. GitLab Flow 당첨!

---

프로젝트에 적용하기

브랜치 구조

위에서 말한 조건들을 충족시키기 위해 다음과 같은 구조를 사용하기로 했습니다.

feature/* → main → pre-production(QA 환경) → production(배포 환경)

주의할 점은 pre-production이 git-flow의 release브랜치와 비슷하지만, GitLab flow에서는 pre-production에서 작업을 진행하지 않는다는 것입니다.
(git flow에서는 release 브랜치에서 QA 반영 등 수정 작업을 진행함.)

브랜치 네이밍

프로젝트 상황에 따라 브랜치 이름에 포함되어야 할 내용이 많았습니다.

모노레포 구조이므로 프로젝트 이름을 포함시키고 싶었고,
브랜치(기능)별로 Issue를 생성하므로 Issue 번호도 포함 시키고 싶었습니다.

브랜치 네이밍 규칙
{type}/{project_name}/title-{Issue_No}
ex) feat/service/setting-#28, fix/admin/login-bug-#36

그래서 위와 같이 브랜치 이름을 정하기로 했습니다.

조금 길다고 느껴질 수 있지만, 더 명확하고 나중에 봤을 때 뭔지 바로 알 수 있는 네이밍을 하고 싶어서 해당 정보들을 모두 포함시키기로 하였습니다.

브랜치 병합 방식

feature → main

GitLab Flow 구조 특성상, 코드의 모든 추가/수정 작업은 feature 브랜치에서만 일어납니다.

따라서 feature → main 으로 갈때는 Github PR을 이용하고, 충분한 코드리뷰를 진행하고 머지하기로 하였습니다.

main → pre-production

테스트 환경으로 배포되는 병합이긴 하지만, 그래도 배포가 되는 과정이기 때문에

• 어떤 작업이 포함된 배포이고
• 문제가 없는지 더블 체크한다는 점에서

기본적으로는 PR을 이용한 병합을 진행하기로 하였습니다.

하지만, feature → main 에서 리뷰가 모두 이루어진 코드들이므로,
간단한 수정 등 상황에 따라 PR 없이 merge하는 것도 가능하게 하기로 하였습니다.

pre-production → production

QA 환경에서 테스트를 거치고 실제 배포로 병합되는 과정으로, 추가 리뷰 없이 바로 merge 하기로 하였습니다.

QA 반영 및 버그 수정은 새로운 feature 브랜치에서 작업하고, 리뷰를 거쳐 pre-production까지 왔을테니, 여기서는 추가 리뷰를 진행하지 않기로 하였습니다.

결론

다양한 브랜치 전략에 대해서도 알게 되었고, 프로젝트 규모와 상황에 맞는 적절한 전략을 선택하는 것이 중요하다는 것도 다시 한번 알게되었습니다.

저처럼 Git Flow 가 너무 복잡하다고 생각하신다면, GitLab Flow를 도입하는 것을 고려해보세요!

참고자료

• https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
• https://docs.github.com/en/get-started/using-github/github-flow
• https://about.gitlab.com/topics/version-control/what-is-gitlab-flow/
• https://www.alexhyett.com/git-flow-github-flow/
• https://velog.io/@jhchoi94/Git-GitLab-flow