Git 브랜치 전략 3가지

Git은 분산 버전 관리 시스템으로서 훌륭하지만, 팀 내 구성원들이 각자의 방식으로 사용하다보면 코드가 충돌하거나 히스토리 관리가 어려워지는 등 문제가 발생할 수 있습니다.

단순히 Git 명령어를 아는 것을 넘어서, 팀 전체가 동의하고 따를 수 있는 명확한 사용 규칙과 절차가 필요한데요. 언제 어떤 브랜치를 만들고, 언제 병합하고 배포할지에 대한 약속이 없다면, Git은 그저 파일 백업 도구로 전락해버릴지도 모릅니다.

그렇다면 우리는 Git을 어떻게 사용해야 할까요? 이런 문제 의식에서 나온 것이 바로, Git 브랜치 전략입니다.

이번 아티클을 읽으시다보면 우리 팀에 적합한 Git 브랜치 전략을 찾아가실 수 있을 겁니다.

팀이 아니라 혼자서 프로젝트를 진행하고 있다고요? 걱정 마세요. 1인 개발 시 프로젝트 관리에 도움이 되는 Git 브랜치 전략도 추천해드릴 테니까요.

프로젝트를 관리할 때 Git 브랜치 전략이 중요한 이유

(대표적인 Git 브랜치에는 Git 플로우, GitHub 플로우, GitLab 플로우가 있습니다.)

Git 브랜치 전략은 팀이 코드를 개발하고 통합하며 배포하는 전체 과정에 대한 규칙과 절차를 정의하는 방법론입니다. 코드 변경 사항을 체계적으로 관리하고, 프로젝트를 안정적으로 진행하기 위한 기반이 되어주는데요. 그래서 Git 브랜치 전략은…

코드 통합 안정성을 높이고 병렬적 개발을 용이하게 하며,
코드 리뷰 문화를 정착시키면서 코드 품질 향상에 기여하고,
지속적 통합(CI) 및 지속적 배포(CD) 파이프라인과도 자연스럽게 연동될 수 있습니다.

대표적인 Git 브랜치 전략으로는 아래와 같이 3가지가 존재하는데요.

Git 플로우
- 핵심 브랜치(main, develop)와 명확한 목적을 가진 보조 브랜치(feature, release, hotfix)를 활용하는 체계적인 Git 브랜치 전략
GitHub 플로우
- main 브랜치를 항상 배포 가능한 상태로 유지하여 복잡한 규칙 없이 빠른 배포에 적합한 Git 브랜치 전략
GitLab 플로우
- GitHub 플로우의 단순함은 가져가면서, 필요에 따라 환경별 배포를 위한 브랜치(pre-production, production 등) 또는 특정 버전 릴리즈를 위한 릴리즈 브랜치를 추가할 수 있는 유연한 Git 브랜치 전략

우리에게 적합한 방식을 찾아나갈 수 있도록 각 브랜치 전략의 동작 방식과 장/단점에 대해 차근차근 살펴보겠습니다.

Git 플로우

아마도 Git 브랜치 전략에 대해 이미 검색해보셨다면 아래와 같은 그림을 한 번쯤은 보셨을 수도 있습니다. Git 플로우를 나타낸 그래프인데요.

500

그래프가 복잡해보여도 걱정 마세요. 지금 당장 위 그림의 내용을 다 이해할 필요는 없습니다.

다만 우리가 주목해야 할 것은 볼드체로 강조된 master(또는 main) 브랜치와 develop 브랜치가 Git 플로우의 핵심 브랜치라는 점입니다.

Git 플로우의 동작 방식

Git 플로우의 중심에는 항상 유지되는 두 개의 핵심 브랜치(main, develop)가 있습니다. 그리고 이를 보조해주는 보조 브랜치(feature, release, hotfix)가 존재하죠.

main 브랜치
- 실제 프로덕션에 배포된 안정적인 버전의 코드가 포함된 브랜치
- 태그를 통해 각 릴리즈 버전 관리
develop 브랜치
- 다음 릴리즈를 위해 개발 중인 최신 코드가 포함된 브랜치
- 모든 기능 개발의 기준
feature 브랜치
- 새로운 기능을 개발하거나 기능 개선이 필요할 경우, develop 브랜치로부터 feature/{기능 이름}와 같은 이름으로 분기됨
- 각 기능은 독립된 feature 브랜치에서 개발 후, 개발 완료 시 다시 develop 브랜치로 병합
- 병합이 완료된 feature 브랜치는 삭제
release 브랜치
- develop 브랜치에 다음 릴리즈를 위한 기능들이 충분히 통합되었다고 판단될 경우, develop 브랜치로부터 release/{버전 번호}와 같은 이름으로 분기됨
- 본 브랜치에서는 배포를 위한 최종 테스트와 문서 작업, 이 과정에서 발견된 버그 수정 작업만 진행
- 배포 준비가 완료되면 main 브랜치와 develop 브랜치로 병합
- 병합이 완료된 release 브랜치는 삭제
hotfix 브랜치
- 이미 프로덕션에 배포된 main 브랜치의 코드에서 긴급 수정이 필요한 버그 발생 시 hotfix/{버그 이슈 번호}와 같은 이름으로 분기됨
- 작업 완료 후 main 브랜치와 develop 브랜치로 병합
- 병합이 완료된 hotfix 브랜치는 삭제

Git 플로우의 장/단점

지금까지 살펴본 내용을 보면, Git 플로우는 체계적이고 명확하게 브랜치가 나눠지고 합쳐짐을 알 수 있는데요. 이런 Git 플로우의 장점과 단점을 정리하면 아래와 같습니다.

장점:

여러 개발자가 동시에 다양한 작업을 수행하는 대규모 프로젝트에서도 코드 관리의 혼란을 줄이고, 체계적인 버전 관리가 가능
release 브랜치를 통해 안정적인 배포판을 준비하는 과정과, hotfix 브랜치를 통해 운영 환경의 긴급한 문제를 신속하게 해결하는 명확한 절차를 제공

단점:

이미 다양한 브랜치 종류와 각 브랜치의 병합 규칙이 정해져 있어 처음 접하는 팀에게는 복잡하게 느껴질 수 있음
release 브랜치를 통한 별도의 배포 준비 과정은, 배포가 매일 또는 수시로 이루어지는 현재 웹 서비스 환경에서는 다소 번거롭고 느릴 수 있음
브랜치 관리가 복잡하여 지속적 통합(CI) 및 지속적 배포(CD) 파이프라인과 완벽하게 통합이 어려울 수 있음

GitHub 플로우

GitHub 플로우는 Git 플로우의 복잡성을 최소화하기 위해 나온 브랜치 전략입니다. 이를 도식화한 아래 이미지만 봐도, 위에서 봤던 Git 플로우보다 많이 간소화된 걸 알 수 있죠?

(출처: https://symphony.is/about-us/blog/git-your-branching-together-branching-models-compared)

GitHub 플로우의 동작 방식

GitHub 플로우의 핵심 원칙은 main 브랜치가 항상 안정적이고, 즉시 프로덕션에 배포될 수 있는 상태를 유지하는 것입니다. 모든 개발 작업은 main 브랜치에서 시작되며, 병합되기 전까지 충분히 테스트와 리뷰를 거치는 건데요.

기능 추가나 버그 수정 등 모든 새로운 작업은 main 브랜치로부터 분기된, 피처 브랜치(Feature Branch)라 불리는 브랜치에서 진행됩니다. 보통 피처 브랜치는 해당 작업의 내용을 설명하는 이름(예: fix-login-bug, add-user-profile)으로 만들어지죠.

이런 피처 브랜치에서의 작업이 모두 완료되면 main 브랜치에 병합됩니다. main 브랜치의 코드는 곧 프로덕션 배포용 코드이기 때문에, main 브랜치로 병합 시 자동으로 동작하는 CI/CD 파이프라인을 구성하기 좋습니다.

GitHub 플로우의 장/단점

Git 플로우에 비해 크게 간소화된 GitHub 플로우는 그 장/단점도 명확합니다.

장점:

main 브랜치와 피처 브랜치라는 최소한의 브랜치 종류만 사용하여 도입 및 교육 부담이 적음
main 브랜치에 병합된 코드는 즉시 배포 가능 상태이므로, 하루에도 여러 번 배포가 가능한 신속한 개발과 배포 사이클 구현 가능
CI/CD 파이프라인을 구축하고 자동화하는 데에 매우 유리함

단점:

main 브랜치가 항상 최신 배포 버전을 나타내기 때문에, 특정 시점의 코드를 고정하여 별도의 버전으로 관리하거나, 여러 버전을 동시에 유지보수해야 하는 전통적인 소프트웨어 릴리즈 방식에는 적합하지 않음
긴급 수정을 위한 별도 절차가 정의되어 있지 않으므로, 상황에 따라 대처해야 할 수 있음

GitLab 플로우

GitLab 플로우는 GitHub 플로우의 핵심 원칙인 ‘main 브랜치 중심의 개발’을 유지하면서, 프로젝트의 필요에 따라 추가적인 브랜치를 유연하게 도입할 수 있도록 설계되었습니다. 즉, ‘단순함’과 ‘체계적인 관리’를 모두 취하고자 나온 전략이죠.

500 (출처: https://lab.las3.de/gitlab/help/workflow/gitlab_flow.md)

GitLab 플로우의 동작 방식

먼저 GitLab 플로우가 GitHub 플로우와 유사한 점은 아래와 같습니다.

main 브랜치
- 프로덕션 환경에 배포된 안정적인 코드 포함
feature 브랜치
- 모든 새로운 기능 개발과 버그 수정이 이루어짐
- main 브랜치로부터 분기되며, 작업이 완료되면 main 브랜치로 병합

그리고 체계적인 코드 관리를 위해 GitLab 플로우에서 사용할 수 있는 브랜치는 아래와 같습니다.

환경 브랜치 (예: pre-production, production)
- 스테이징이나 프로덕션과 같이 각 배포 환경에 대응
- main 브랜치에서 pre-production 브랜치로 코드를 병합하여 스테이징 환경에 배포 후, 충분히 테스트를 완료하면 pre-production 브랜치에서 production 브랜치로 병합하여 실제 운영 환경에 배포
release 브랜치
- 정기적인 릴리즈나 특정 버전 관리가 필요한 경우, release/{버전 번호} 형태의 브랜치 생성
- 해당 버전의 안정화 작업 및 버그 수정이 완료되면 프로덕션 환경에 배포 및 main 브랜치에 병합

GitLab 플로우의 장/단점

GitHub 플로우의 ‘단순함’과 Git 플로우의 ‘체계성’을 모두 취하고자 했던 GitLab 플로우의 장/단점은 아래와 같습니다.

장점:

간결한 기본 흐름을 유지하면서도 환경 브랜치나 릴리즈 브랜치 도입으로 유연한 운영 가능
GitLab 플랫폼 내에서 GitLab 플로우를 사용할 경우, 전체 개발 라이프사이클을 이슈와 연계하여 효과적으로 추적 및 관리 가능

단점:

GitHub 플로우보다는 복잡성이 증가

우리 프로젝트에 맞는 Git 브랜치 전략은 뭘까?

이렇게 3가지 Git 브랜치 전략의 동작 방식과 장/단점에 대해 알아봤는데요. 각 브랜치 전략이 적합한 시나리오도 아래와 같이 정리했으니, 나에게 맞는 Git 브랜치 전략을 찾고 계신다면 도움이 될 겁니다.

Git 플로우가 적합한 경우

여러 팀이나 다수의 개발자가 참여하여 각자의 역할을 수행하고, 개발 프로세스가 명확하게 정의된 팀
여러 버전을 동시에 유지보수해야 하거나 명확한 버전 관리가 필수적인 소프트웨어 개발 시
- 예: 임베디드 소프트웨어, 라이브러리 등

GitHub 플로우가 적합한 경우

빠르게 기능을 구현하면서 개발 히스토리를 기록하고 싶은 1인 개발자
애자일 방법론을 따르는 소규모 팀
지속적인 기능 개선과 사용자 피드백 반영이 중요한 웹 서비스, SaaS, 모바일 앱 등 개발 시

GitLab 플로우가 적합한 경우

GitHub 플로우를 적용해왔지만 여러 릴리즈 버전이나 다양한 배포 환경이 필요하게 된 팀
GitLab 플랫폼을 사용하면서 전체 작업 현황의 가시성을 높이고 싶은 팀

마무리

지금까지 대표적인 Git 브랜치 전략 3가지에 대해 살펴봤는데요. 어떠신가요? 여러분에게 유용한, 또는 관심이 가는 GIt 브랜치 활용법을 찾으셨나요?

물론 이런 전략 하나를 고르고 무조건 그대로 고수해야만 하는 것은 아닙니다.

어디까지나 프로젝트를 지금보다 좀 더 효율적으로 관리하기 위함이 Git 브랜치 전략의 목적이기 때문에, 프로젝트 상황에 따라 팀 내에서 합의를 했다면 브랜치 전략의 일부 수정하는 등 유연하게 도입할 수 있는 것이죠.

Git을 사용 중이긴 하지만 체계적인 브랜치 활용 방법이 궁금하셨거나, 새로 시작한 프로젝트를 효율적으로 관리하고 싶으신 분들에게 도움이 되었길 바랍니다.

그럼 다음주에 더 흥미로운 주제를 가지고 돌아오겠습니다. 감사합니다.

🔭Aiden's Lab

최근 게시글

Kyverno 핵심 기능 3가지 실습 가이드 (feat. minikube)