Appearance
🚀 Git 브랜치 전략 문서
- 추가적인 notion 과 Git hub 연결 하기
🔍 개요
본 프로젝트는 GitHub + GitHub Actions 기반의 CI/CD 환경에서 운영될 예정입니다.
이를 고려하여 다음과 같은 요구사항을 만족하는 브랜치 전략을 수립합니다:
- 빠른 배포가 가능한 단순한 구조
- 필요 시 QA를 거쳐 릴리즈할 수 있는 유연한 대응력
- GitHub Actions와 자연스럽게 연동되는 워크플로우
이에 따라 GitHub Flow와 GitLab Flow의 장점을 결합한
Hybrid 브랜치 전략 (GitHub Flow + GitLab Flow) 을 채택합니다.
✅ 선택된 브랜치 전략: Hybrid Flow
📌 브랜치 구조
| 브랜치명 | 용도 |
|---|---|
main | 운영(프로덕션) 환경. 배포 자동화 트리거 |
feature/* | 기능 개발용 브랜치 |
staging (선택적) | QA 또는 테스트 환경에서의 검증용 브랜치 |
hotfix/* | 버그 발생 시 올리는 처리용 브런치 |
🧪 워크플로우
▶ 기본
staging에서feature/기능명브랜치 생성- 기능 개발 및 테스트
- Pull Request → 리뷰 후
staging에 merge 후main으로 merge mainmerge 시 GitHub Actions 트리거 → 자동 배포
✅ 빠르고 단순한 GitHub Flow 스타일
✅ 이 전략의 장점
- ⚡ 빠른 배포 루프 지원
- 🧪 QA 필요 시 검증용 브랜치(staging) 통해 안정성 확보 가능
- 🤝 협업, 리뷰, 자동화 테스트 등 GitHub 기능과 완벽히 호환
- 🧱 브랜치 구조가 간단하여 운영 및 교육이 쉬움
⚠️ 유의사항
- QA 여부, staging 사용 여부에 대한 팀 내부 기준 정의 필요
staging에서main으로 merge 시점은 QA 완료 후로 통일- 긴급 수정 시
hotfix/버그명브랜치를 사용하고 바로main에 PR 가능
🧾 전략 선택 요약 문구
본 프로젝트는 GitHub Actions 기반의 CI/CD 파이프라인을 운영하므로, 빠른 배포를 위한 GitHub Flow를 기본으로 채택하되, QA가 필요한 경우에는 GitLab Flow의 staging 브랜치 전략을 혼합 적용하는 Hybrid 전략을 사용합니다.
이를 통해 품질과 속도, 두 마리 토끼를 잡는 브랜치 전략을 구현합니다.
🧭 Git 브랜치 전략 비교
🔄 대표 브랜치 전략 비교
| 전략명 | 브랜치 구조 | 특징 | 장점 | 단점 | 추천 상황 |
|---|---|---|---|---|---|
| Git Flow | main, develop, feature/*, release/*, hotfix/* | 클래식한 릴리즈 전략 | QA/릴리즈 분리 명확, 안정성 ↑ | 복잡함, 느림 | 릴리즈 주기 긴 서비스 |
| GitHub Flow | main, feature/* (PR 기반) | 단순하고 빠름 | PR 기반 협업, 자동 배포와 궁합 좋음 | QA 없음, 릴리즈 통제 어려움 | 스타트업, 소규모 팀 |
| GitLab Flow | main, feature/*, (staging,production 등 환경별 브랜치) | 환경/이슈 기반 전략 | QA 브랜치 활용 가능, CI/CD 연동 쉬움 | 팀별 설정 다양, 관리 필요 | QA와 자동화 모두 필요한 팀 |
| Trunk-Based Dev | main(or trunk)만 사용 (단기 브랜치 가능) | 지속 통합 중심 | 병합 충돌 적음, 빠른 피드백 | 테스트 자동화 필수, 대규모 개발 어려움 | DevOps 강한 팀, 자동 테스트 성숙한 팀 |
📌 선택 기준 요약
| 조건 | 추천 전략 |
|---|---|
| QA 없음, 빠른 배포 필요 | GitHub Flow |
| QA 있음, 릴리즈 품질 중요 | Git Flow / GitLab Flow |
| QA 유동적, CI/CD 사용 | ✅ Hybrid (GitHub + GitLab Flow) ← 현재 전략 |
| 테스트 자동화 성숙, 초고속 배포 | Trunk-Based Development |
📎 전략별 구조 도식 (텍스트 기반)
bash
1. Git Flow
main
├── develop
│ ├── feature/a
│ ├── feature/b
│ └── release/*
└── hotfix/*
2. GitHub Flow
main
├── feature/a
└── feature/b
(PR 기반 병합)
3. GitLab Flow
production
├── staging
│ ├── main
│ │ ├── feature/a
│ │ └── feature/b
│ └── hotfix/*
└── hotfix/*
4. Trunk-Based Development
main(trunk)
├── branch/a (단기)
└── branch/b (단기)
5. Hybrid Flow (현재 채택)
main
├── staging (선택적)
│ ├── feature/a
│ ├── feature/b
│ └── hotfix/*
└── feature/* (QA 불필요 시 직접 병합)💡 최적화된 전략 제안
현재 채택한 Hybrid Flow는 다음과 같이 최적화하여 운영할 것을 제안합니다:
- 브랜치 명명 규칙 표준화:
- feature/[타입]-[설명] (예: feature/feat-login)
- hotfix/[버그ID]-[설명] (예: hotfix/bug123-password-reset)
- 자동화 규칙:
- GitHub Actions를 통한 자동 테스트
- Lint/포맷팅 체크
- PR 템플릿 적용
- PR 프로세스 최적화:
- 코드 리뷰어 자동 지정
- PR 사이즈 제한 (300줄 이하 권장)
- PR 설명 템플릿 표준화
- 배포 프로세스:
- staging → QA 자동 배포
- main → Production 수동 승인 후 자동 배포
- 릴리즈 노트 자동 생성
이러한 최적화를 통해 개발 생산성과 코드 품질을 동시에 향상시킬 수 있습니다.
🏷️ Git 태그 전략
태그는 코드베이스의 중요한 시점을 표시하는 데 사용됩니다.
📌 태그 명명 규칙 ( 시맨틱 버저닝 )
- 형식: v[Major].[Minor].[Patch]
- 예시: v1.0.0, v1.2.3
🔄 태그 생성 시점
- 주요 기능 출시 (Major 버전)
- 기능 추가 (Minor 버전)
- 버그 수정 (Patch 버전)
⚙️ 태그 관리 프로세스
- 릴리즈 준비가 완료되면 태그 생성
- 태그에 상세한 릴리즈 노트 첨부
- GitHub Release 기능 활용하여 관리
🤖 자동화 연동
- 태그 생성 시 자동 배포 트리거
- 릴리즈 노트 자동 생성
- 관련 이슈/PR 자동 연결
태그는 프로젝트의 중요한 이정표를 표시하고, 배포 버전을 추적하는 핵심 도구입니다.
CI / CD 추가 작업 예상 부분
- deploy 이후, CURL 등을 이용하여 200번이 정상적으로 return 되는지 확인 ( 5xx 등의 이슈는 role back 처리 )
- 이후 롤백 되었는지, 아니면 정상 배포가 완료되었는지 slack 혹은 notion 에 알림 발송