브랜치 전략 바꾸기

프로젝트를 진행하며 Git 브랜치 전략을 사용하고 계신가요? 저는 Git flow 방식을 사용하고 있었습니다. 그러나 프로젝트를 진행하다보니 해당 방식이 프로젝트에 적합하지 않다는 생각이 들었습니다. 프로젝트에 적합한 브랜치 전략을 찾기 위해 조사해 본 결과 다양한 브랜치 전략이 있다는 것을 알게 되었습니다. 오늘의 브랜치 전략은 무엇인지, 브랜치 전략에는 어떤 것이 있으며 최종적으로 제가 선택한 브랜치 전략은 무엇인지 이야기해보도록 하겠습니다.

브랜치 전략이란?

브랜치 전략이란 Git을 사용할 때 브랜치의 역할에 따라 코드를 관리하는 방법론입니다. 프로젝트의 요구사항에 따라 브랜치를 사용하는 규칙과 구조를 정의하여 일관성 있게 코드를 관리합니다.

그렇다면 브랜치 전략을 사용하는 이유는 무엇일까요? 하나의 브랜치에서 여러 명의 개발자가 개발한다고 가정해 보겠습니다. 각각의 개발자가 작업을 한 후에 하나의 브랜치에 커밋하게 되면 같은 파일을 수정한 경우 머지 충돌이 발생할 것입니다. 이를 해결하느라 불필요한 시간을 소모하게 되며 작업의 효율성이 떨어지게 됩니다. 또한 어느 커밋을 기준으로 QA, 배포할지 혼란스러우며 프로젝트 히스토리 관리도 어려울 것입니다. 따라서 기능 개발, 버그 수정, QA, 배포 등 브랜치의 역할을 나누어 코드를 관리하는 브랜치 전략을 도입하여 프로젝트의 운영의 효율성과 안정성을 높이는 것이 중요합니다.

혼자 작업 하는데도 브랜치 전략이 필요할까?

사실 배포 전에는 따로 브랜치를 생성하지 않고 main 브랜치에 push를 하곤 했습니다. 하지만 배포를 한 이후에는 Vervel을 통해 push가 발생하면 자동으로 배포되도록 세팅해두었기 때문에 브랜치 전략이 필요해졌습니다. tag가 push 되었을 때 배포하는 방법도 있지만 저는 배포 브랜치를 정해두고 해당 브랜치에 push가 발생할 때 배포되는 것이 직관적이라 생각되어 개인 프로젝트에도 브랜치 전략을 도입하였습니다. 각자의 필요에 따라 다르겠지만 프로젝트가 배포되고 있다면 브랜치를 나누어 작업하는 것이 안정적이라고 생각됩니다.

어떤 브랜치 전략을 도입할까

결론부터 말하자면 저는 GitLab flow를 선택했습니다. 이유는 Git flow보다는 단순하고 Github flow보다는 브랜치의 역할 분담이 잘 되어 있기 때문입니다.

사실 처음에는 원래 알고 있던 Git flow 방식을 관성적으로 사용했습니다. 그러나 작업을 하다 보니 개인 프로젝트에서는 Git flow 전략이 다소 복잡하다는 생각이 들었고 대안을 찾기 위해 다른 브랜치 전략을 조사하게 되었습니다. 그럼 많이 사용되는 3가지 브랜치 전략을 살펴보겠습니다.

Git flow

Git flow는 main, develop, feature, release, hotfix와 같은 5가지 브랜치를 사용합니다. 소개하는 3가지 전략 중 가장 복잡하지만 브랜치의 역할을 명확히 나누어서 안정적으로 코드 관리를 해나갈 수 있습니다. 다수의 인원이 모인 팀에서 사용하기 적절합니다. 저도 회사에 다니며 사용하였던 브랜치 전략이지만 개인 프로젝트에 적용하기에는 다소 번거롭다는 단점이 있습니다.

브랜치 역할

• main (master) : 테스트, QA 등 모든 검증이 완료된 프로덕션 배포용 브랜치. release, hotfix 등 배포 후 develop 브랜치와 동기화 필요.
• develop : 개발용 브랜치. develop 브랜치를 기준으로 기능 개발.
• feature : 기능 개발용 브랜치로 develop 브랜치에서 분기 후 병합.
• release : 배포 준비를 위한 브랜치로 QA 및 수정 작업이 진행. 배포 준비가 완료되면 main 브랜치에 병합.
• hotfix : 긴급한 에러를 수정하기 위한 브랜치로 main 브랜치에서 분기 후 병합.

GitLab flow

GitLab flow는 GitLab에서 제안하는 브랜치 전략입니다. 항상 유지되는 main 브랜치가 있으며 필요에 따라 환경 브랜치(production, pre-production 등)를 추가할 수 있습니다. 배포할 준비가 코드가 포함된 main 브랜치가 있으나 해당 브랜치에서 배포를 진행하지 않습니다. 배포를 위해 production 브랜치를 생성하며 배포 전 QA 과정이 필요하다면 pre-production 브랜치를 생성할 수도 있습니다. GitLab에서 제안하는 GitLab flow의 모범 사례를 보면 기능 개발 시에 main 브랜치를 기준으로 feature 브랜치를 생성할 것을 권장하고 있습니다.

브랜치 역할

• main : 배포할 준비가 된 브랜치.
• production : 프로덕션 배포용 브랜치.
• pre-production : 배포 전 QA를 진행하는 브랜치
• feature : 기능 개발용 브랜치. main에서 분기 후 병합

Github flow

main 브랜치와 feature 브랜치를 사용하는 브랜치 전략입니다. 소개하는 3가지 전략 중 가장 단순한 구조입니다. feature 브랜치에서 작업을 완료하고 바로 main 브랜치에 병합하는 방식으로 빠르게 기능을 개발하고 배포할 수 있다는 장점이 있습니다.

브랜치 역할

• main : 프로덕션 배포용 브랜치.
• feature : 기능 개발을 위한 브랜치, main 브랜치에서 분기 후 병합.

앞서 언급했듯이 저는 GitLab flow 방식의 브랜치 전략을 사용하고 있습니다. 개인 프로젝트이다 보니 Git flow의 main과 develop 브랜치를 동기화하는 작업이 번거롭게 느껴졌고 간단한 QA는 Vercel에서 제공하는 preview 배포 기능을 통해 develop 브랜치에서 진행하고 있었기에 release 브랜치의 필요성을 느끼지 못했습니다. 하지만 Github flow처럼 feature 브랜치에서 바로 main 브랜치로 merge하는 것은 안정성이 떨어진다고 생각하였기에 GitLab flow 방식을 최종적으로 선택하였습니다. 환경에 따라 브랜치를 유연하게 추가할 수 있다는 점도 큰 매력 포인트였습니다.

포스팅을 마무리하며

오늘은 프로젝트에 맞게 브랜치 전략을 바꾸기 위해 3가지 브랜치 전략의 특징에 대해 알아보았습니다. 해당 포스트에서 소개한 3가지 외에도 다양한 브랜치 전략이 존재합니다. 각자 프로젝트의 성격에 따라 적합한 브랜치 전략을 도입해보면 좋을 것 같습니다 👍