[FE] Git 컨벤션 & 리뷰 규칙

브랜치 전략

• 기능 별로 "feature/#이슈번호" 브랜치를 따서 개발합니다.
• 개발 중인 코드는 develop/fe 브랜치에서 관리합니다. 기능 개발이 완료되면 feature 브랜치를 dev 브랜치에 병합합니다.

📌 메인 브랜치

• main (배포 브랜치)
  • 실제 프로덕션(배포) 버전 관리
  • 배포 직전에만 dev 브랜치에서 병합

---

📌 개발 브랜치 (서브 브랜치)

• develop/fe (프론트엔드 개발)

  • 프론트엔드 전용 개발 브랜치
  • feature/#이슈번호에서 개발 후 병합

• develop/be (백엔드 개발)

  • 백엔드 전용 개발 브랜치
  • feature/#이슈번호에서 개발 후 병합

---

📌 기능/수정 브랜치 (단기 브랜치)

• feature/#이슈번호

  • 새로운 기능 개발을 위한 브랜치
  • 완료 후 develop/fe 또는 develop/be로 병합

• refactor/#이슈번호

  • 기존 코드 리팩토링을 위한 브랜치

---

📌 배포 및 핫픽스 브랜치

• release/#버전

  • 배포 준비 및 최종 버그 수정 후 main으로 병합

• hotfix/#이슈번호

  • 프로덕션 긴급 버그 수정
  • main에서 파생 후, 수정 완료 시 main 및 dev에 병합

---

✅ 2. 브랜치 전략 흐름 (개발 사이클)

📌 기능 개발 (일반 개발 흐름)

develop/fe 또는 develop/be → feature/#이슈번호 생성
feature/#이슈번호 → develop/fe, develop/be 병합
develop/fe, develop/be → dev 병합
dev → release/#버전 (최종 테스트)
release/#버전 → main 병합



- 커밋 메시지 규칙
    - (이모지 타입 이모지) (커밋 타입): 커밋 설명
        - ✨ feat : `새로운 기능 추가에 관한 커밋`
        - 🐛 fix : `버그 수정에 관한 커밋`
        - 📝 docs : `문서 작성에 관한 커밋`
        - ♻️ refactor : `리팩토링 작업에 관한 커밋`
        - 🚚 chore : `기타 자잘한 코드 수정에 관한 커밋`
    - stage 후, pnpm commit 명령어를 이용하면 위 구조에 맞도록 쉽게 커밋할 수 있습니다.



## PR 컨벤션

**제목**

```c
[feature]: ~ 기능 추가

조건

• PR은 반드시 작게!
• 모든 커밋을 다 설명하진 말자
• 리뷰가 필요한 핵심 기능만 설명
• 설명 - 커밋번호
  • 코드 넣지말고 커밋 번호만 추가

리뷰

• 참고하거나 GPT를 사용한 코드라면 반드시 명시하기
• 24시간 안에 리뷰
• 혼자가 아닌 함께 하는 일이기에 우리 모두는 코드 리뷰에 책임감을 갖습니다.
• 인프라 작업이나 릴리즈 PR은 리뷰를 생략할 수 있습니다.
• 리뷰하기에 양이 많다면, 오프라인 리뷰를 요청하시길 바랍니다.
• 특별히 신경을 써야 할 리뷰 포인트는 코멘트를 남겨주시면 좋습니다.