FE Git Convention

✅ 기본적인 브랜치 구조

main
│
├── dev  ← (기능 개발 브랜치들의 베이스)
│   ├── feat/feature-name  (새로운 기능 개발)
│   ├── fix/bugfix-name  (버그 수정)
│   ├── style/ui-update  (스타일 변경)
│   ├── refactor/code-refactor  (리팩토링)
│   ├── chore/dependency-update  (의존성 업데이트)
│
└── release/next-version  (배포 전 테스트 브랜치)

🌟 1. 브랜치 역할 정의

브랜치	역할
`main`	최종 배포용 브랜치, 직접 작업 X
`dev`	개발용 브랜치, 모든 기능 브랜치는 여기서 시작
*`feat/`**	새로운 기능 개발 (`feat/login`, `feat/dashboard-ui`)
*`fix/`**	버그 수정 (`fix/navbar-bug`, `fix/api-error`)
*`style/`**	스타일 변경 (`style/button-redesign`)
*`refactor/`**	코드 리팩토링 (`refactor/hook-optimization`)
*`chore/`**	설정 변경, 패키지 업데이트 (`chore/eslint-update`)
*`release/`**	배포 전 최종 검토 브랜치 (`release/v1.0.0`)

🌍 2. 협업 프로세스

기능 개발 시작
- dev 브랜치에서 새로운 기능 브랜치(feat/feature-name) 생성
- git checkout -b feat/login dev
기능 개발 & 커밋
- feat/*, fix/*, style/* 브랜치에서 작업
- 커밋 메시지는 명확하게
```
feat: 로그인 UI 추가
fix: 모바일 화면에서 버튼 깨지는 문제 해결
```
PR(Pull Request) & 코드 리뷰
- 기능 브랜치를 dev으로 PR
- 팀원들 코드 리뷰 후 dev에 머지
테스트 및 배포
- 배포 전 release/* 브랜치에서 QA 테스트 진행
- main 브랜치로 머지 후 배포

🚀 3. 브랜치 네이밍 가이드

타입	예시
기능 개발	`feat/auth-login`, `feat/profile-page`
버그 수정	`fix/header-bug`, `fix/api-timeout`
UI 스타일링	`style/navbar-update`, `style/theme-darkmode`
리팩토링	`refactor/useFetch-hook`, `refactor/state-management`
패키지 설정	`chore/vite-config-update`, `chore/dependency-upgrade`
배포 준비	`release/v1.0.0`

🔥 4. 브랜치 전략 시 주의할 점

✅ 작업 전 dev 최신 코드 반영

git checkout dev
git pull origin dev
git checkout -b feat/new-feature