브랜치 전략 (GitHub Flow · Git Flow · 버전 관리)
GitHub Flow를 중심으로 Git Flow 등 다른 브랜치 전략과 비교하고, 릴리즈에 붙이는 버전 관리 전략까지 이어서 다룹니다.
GitHub Flow
GitHub Flow는 GitHub가 제안한, 단순하고 명확한 브랜치 전략입니다. 핵심은 하나입니다.
main(또는master) 브랜치는 항상 배포 가능한 상태를 유지한다.
Feature 브랜치
새로운 기능이나 수정 사항마다 별도의 브랜치를 파서 작업하고, 끝나면 메인 브랜치로 머지하는 개념입니다. 여러 기능을 독립적으로 개발할 수 있고, 여러 명이 동시에 작업해도 충돌이 최소화됩니다.
작업 흐름
- 메인 브랜치에서 새 브랜치 생성
- 브랜치에서 작업
- Pull Request 생성
- 코드 리뷰
- 머지
"항상 배포 가능"은 어떻게 보장할까?
두 가지 장치가 필요합니다.
- 코드 리뷰: 머지 전에 사람이 눈으로 오류를 걸러냅니다. 다만 사람이 하는 일이라 놓치는 부분이 생길 수밖에 없습니다.
- 테스트 (자동화된 CI): 브랜치를 체크아웃해 빌드하고 테스트를 자동으로 돌려서, 리뷰 전에 이미 "배포 가능함"이 확인된 상태로 만듭니다.
현실에서 부딪히는 고민들
프로젝트 초기라 구조가 계속 바뀔 때: 아직 팀의 디자인 패턴이 정립되지 않은 상태에서 다들 다른 방식으로 코드를 짜면, 방법론 충돌이 곧 코드 충돌로 이어집니다. 이럴 땐 먼저 모여서 방향성과 규칙을 정하거나, 한 명이 빠르게 프로토타입으로 구조를 검증한 뒤 GitHub Flow를 도입하는 게 낫습니다.
Feature의 크기가 애매할 때: "무엇을 하나의 Feature로 볼지"는 회사·프로젝트·사람마다 다릅니다. 다음 기준이 도움이 됩니다.
- 구체적으로 정의할 것 (예: "UI 개선" 대신 "로그인 버튼 디자인 변경")
- 독립적으로 배포 가능할 것
- 배포 시점에 다른 코드와 충돌 없이 호환될 것
- 너무 크지도 작지도 않은 적절한 크기일 것
Git Flow vs GitHub Flow, 그리고 다른 전략들
왜 두 전략이 따로 생겼을까
2010년대 초의 소프트웨어는 정해진 주기로 배포됐고, 큰 업데이트 전에는 상당한 준비 기간이 필요했습니다. 이 시절 CI는 초기 단계였고 CD(지속적 배포)는 대중화되기 전이었죠. 그래서 master, develop을 중심에 두고 feature, release, hotfix 브랜치로 세분화한 복잡한 모델, Git Flow가 등장했습니다. 주기적인 릴리즈와 갑작스런 핫픽스를 체계적으로 관리하기 위한 도구였습니다.
시간이 지나 CI/CD가 발전하면서 배포 빈도가 극적으로 빨라졌습니다(하루에 여러 번 배포하는 회사도 생겼죠). 이런 환경에는 복잡한 브랜칭보다 간결한 모델이 필요해졌고, 그렇게 main + feature 브랜치만 쓰는 GitHub Flow가 주목받게 됩니다.
비교
| GitHub Flow | Git Flow | |
|---|---|---|
| 브랜치 구조 | main + feature | master, develop, feature, release, hotfix |
| 좋은 상황 | 간단하고 빠른 개발, 항상 최신 버전 공개 | 여러 버전 동시 관리, 복잡하고 체계적인 관리 필요 |
| 대표 예시 | 자주 업데이트하는 웹 서비스 | 과거 버전 지원이 필요한 라이브러리, 여러 회사 대상 B2B 소프트웨어 |
GitLab Flow: 두 전략의 절충안
GitLab Flow는 GitHub Flow와 Git Flow의 장점을 섞어 CI/CD 환경에 최적화한 전략입니다. main, feature 외에 environment 브랜치를 추가로 씁니다. 실제 서비스가 도는 production, 개발 중인 develop뿐 아니라 QA·stage 같은 추가 환경까지 각각 브랜치로 나누고, 해당 브랜치에 머지되면 그 환경으로 즉시 배포되도록 CI/CD 파이프라인을 구성합니다. 배포 시나리오가 다양한 팀에 유리하지만, 브랜치 종류가 많은 만큼 초기 학습 비용과 동기화 관리 부담이 있습니다.
Trunk Based Development: 극단적으로 빠른 통합
main(trunk) 브랜치 하나에 거의 모든 작업을 즉시 합치는 전략입니다. GitHub Flow와 비슷하지만 PR 주기가 훨씬 짧아서, 사용자가 눈치채기 힘든 작은 단위까지 바로 main에 머지합니다.
아직 완성되지 않은 기능을 어떻게 배포 가능한 main에 얹을 수 있을까요? 바로 feature toggle입니다. 기능을 코드로는 합쳐두되 사용자에게는 노출하지 않도록 켜고 끌 수 있게 만드는 방식이죠. 덕분에 지속적 통합의 이점을 누리면서도 미완성 기능을 숨길 수 있습니다. 자주 커밋하고 자주 테스트해야 한다는 부담이 있지만, 코드베이스가 크게 벌어지는 걸 막고 배포 리스크를 낮춰줍니다.
버전 관리 전략: Semantic Versioning
SemVer: MAJOR.MINOR.PATCH
**Semantic Versioning(SemVer)**은 가장 널리 쓰이는 버전 관리 방식입니다. MAJOR.MINOR.PATCH 세 숫자로 구성됩니다.
- MAJOR: 호환성이 깨지는 큰 변경 (API 변경, 전면 리뉴얼 등)
- MINOR: 호환되는 새 기능 추가
- PATCH: 호환되는 버그 수정
예를 들어 1.5.3은 "1.0.0 이후 호환되는 기능이 5번 추가되고, 그 과정에서 버그가 3번 수정됐다"는 뜻입니다.
Pre-release: 1.0.0-alpha처럼 하이픈 뒤에 표기하며, 알파/베타/RC 같은 불안정 버전을 나타냅니다. 정식 릴리즈보다 낮은 순서로 취급됩니다. Build metadata: 1.0.0+build20240101처럼 + 뒤에 붙이며, 버전 우선순위엔 영향을 주지 않는 부가 정보입니다.
Date-based Versioning
버전을 숫자 대신 날짜로 표기하는 방식입니다. 예: 우분투의 20.04 LTS(2020년 4월 릴리즈). 언제 나왔는지 바로 알 수 있다는 장점이 있지만, 변경의 크기나 중요도는 알 수 없다는 단점이 있습니다.
GitHub에서의 버전 관리
Git은 Tag로 버전을 관리하고, GitHub는 여기에 더해 release note 작성과 소스코드 압축 다운로드까지 지원합니다. Releases 탭에서 Create a new release를 누르고 태그를 입력한 뒤 Generate release notes를 클릭하면, 그동안의 PR 제목들을 모아 release note를 자동으로 만들어줍니다. PR 제목만 잘 적어둬도 유지보수 문서가 저절로 쌓이는 셈입니다.
정리
| 개념 | 한 줄 요약 |
|---|---|
| GitHub Flow | main을 항상 배포 가능하게 유지, feature 브랜치 + PR로 단순하게 운영 |
| Git Flow / GitLab Flow / Trunk Based | 복잡한 버전 관리(Git Flow), CI/CD 특화 환경 분리(GitLab Flow), 극단적으로 빠른 통합(Trunk Based) |
| Semantic Versioning | MAJOR.MINOR.PATCH로 변경의 크기와 호환성을 버전 번호에 담는 방식 |
출처: Codyssey-B1/B2-2