Git 브랜치 전략
여러 명이 협업을 하거나, 프로젝트의 규모가 커질 때 코드의 안정성과 효율성을 높이기 위해 브랜치를 어떻게 나누고 merge를 하는 지에 대한 정책입니다.
Dev, Stage, Prod branch
- Dev: 새로운 기능 개발과 버그 수정 등 모든 작업의 기반 브랜치 입니다. 실험적인 코드가 포함될 수 있고 안정적이지 않을 수 있으며 개발 완료 후에는 Stage로 병합합니다.
- Stage: 배포 전 최종 테스트 환경입니다. Dev에서 충분히 검증된 코드를 통합 테스트 및 QA 후 Prod로 병합합니다. 실제 운영 환경과 유사한 설정으로 문제를 사전에 발견할 수 있습니다.
- Prod: 실제 사용자에게 제공되는 운영 환경 브랜치입니다. 반드시 안정적이어야 하며, 긴급 수정은 hotfix 브랜치에서 작업 후 바로 병합이 가능합니다.
위험과 대안
- Risky: Staging에서 충분히 검증되지 않은 코드를 Prod에 반영하면 예상치 못한 장애나 사용자 경험 문제가 발생할 수 있습니다. 철저한 QA와 점진적 배포가 중요합니다.
- Slow & Fat Release: 변경 사항이 많을수록 테스트 및 배포하는 시간이 늘어나게 되고, 대규모 릴리스는 문제 발생 시 원인 파악과 복구가 어렵습니다. 작은 단위로 자주 배포하는 small release 전략이 권장됩니다.
브랜치 명칭별 역할
| 브랜치 명칭 | 역할 |
|---|---|
| main | 최종 배포용 브랜치입니다. 최신 안정 코드를 유지합니다. |
| feature | 새로운 기능 개발용 브랜치입니다. develop에서 분기 후 작업 완료 시 develop에서 병합합니다. |
| release | 배포 전 최종 QA 및 버그 수정, develop에서 분기, 완료 후 master와 develop에 병합합니다. |
| hotfix | 운영 중 긴급 버그 수정, master에서 분기, 완료 후 master와 develop에 병합합니다. |
브랜치의 이름을 지을 때는, 목적이 명확하게 드러나도록 지어야합니다.
버전 관리
x.y.z로 표현이 되며, 각 자리에 대해서는
x: 주 버전으로, 호환성이 깨지는 큰 변화가 일어났을 때
y: 부 버전으로, 호환성을 유지하며 기능을 추가했을 때
z: 패치로, 버그 수정 등 작은 변경이 일어났을 때
를 의미합니다.
Git Flow
다양한 브랜치를 명확히 구분해 체계적으로 관리합니다.
대규모 서비스, 안정성이 중요한 프로젝트에 적합합니다.
Github Flow
메인 브랜치와 기능 브랜치만을 사용해 단순하고 빠른 개발 및 배포가 가능합니다.
스타트업, 소규모 프로젝트, 빠른 피드백이 필요한 환경에 적합합니다.
Trunk-based Development(TBD)
오직 하나의 브랜치를 중심으로 개발합니다.
아주 작은 단위로 브랜치를 만들어 빠르게 main에 병합합니다.
대규모 CI/CD, DevOps 환경에서 많이 사용합니다.
