🏗️ 브랜치 아키텍처

1. 브랜치 종류 및 역할

브랜치	설명
main (prod)	- 실제 릴리스 서버(프로덕션)에 배포되는 브랜치
develop (dev)	- 테스트 서버에 배포되는 브랜치- 기능 개발이 완료되면 이 브랜치로 통합- main 브랜치에서 develop 브랜치를 처음 1회 분기
feature	- 새로운 기능 개발을 위한 브랜치- develop 브랜치에서 분기
hotfix	- 프로덕션 이슈를 긴급 수정하는 브랜치- main에서 분기하여, 수정 후 main과 develop 모두에 반영

---

2. 브랜치 흐름 (Workflow)

1. 기능 개발 (Feature Branch)
   • develop 브랜치에서 feature 브랜치를 생성
   • 기능 개발 완료 후, Pull Request(PR)를 통해 develop 브랜치로 병합
2. 테스트 서버 배포 (Develop Branch)
   • develop 브랜치에 변경사항이 병합되면 자동으로 CI/CD를 통해 테스트 서버에 배포
3. 릴리스 준비 및 배포 (Main Branch)
   • develop 브랜치에서 필요한 기능이 모두 완료되면, main 브랜치로 PR을 생성하여 병합
   • 병합 시 버전을 태깅 → (v1.0.0, v1.0.1 등)
   • main 브랜치 병합 시 CI/CD를 통해 프로덕션 서버에 자동 배포
4. 긴급 수정 (Hotfix Branch)
   • 프로덕션에서 긴급 이슈 발생 시, main 브랜치에서 hotfix 브랜치를 생성
   • 수정 완료 후, hotfix 브랜치를 main과 develop 양쪽에 병합하여 버전 관리 및 기능 일관성을 유지

---

3. Release 버전 넘버링: Semantic Versioning (SemVer) 방식

SemVer 정의

• MAJOR (주 버전): 기존과 호환되지 않는 큰 변경이 있을 때 증가
• MINOR (부 버전): 기존 기능과 호환되면서 새로운 기능이 추가될 때 증가
• PATCH (패치 버전): 버그 수정이나 성능 개선만 있을 때 증가

예시 (1.1.0 버전이 기준)

상황	버전 변화 예시
게시판 알림 기능 추가	1.2.0 (Minor 증가)
기존 기능 버그 수정	1.2.1 (Patch 증가)
RT(Refresh Token) 시스템 전체 도입	2.0.0 (Major 증가)

---

4. 주요 규칙

• PR 병합 전 코드 리뷰 필수
• 모든 브랜치는 적절한 네이밍 규칙 준수
  • 브랜치 네이밍 패턴:
    • feature/(이슈번호)/작업할-기능-영어로
    • hotfix/(이슈번호)/작업할-기능-영어로
  • 예시:
    • 로그인 API 개발 → feature/123/login-api
    • 게시글 작성 기능 → feature/456/create-post
• 버전 태깅 필수: 릴리스 시 (vX.Y.Z)
• Hotfix 작업 후 반드시 main과 develop 모두에 반영