Pick&Whip FE 협업 및 개발 규칙

1. Issue 생성 & Branch 전략

• 모든 작업은 Issue 생성부터 시작합니다
• 개인 작업, 기능 추가, 버그 수정 모두 본인 업무에 대한 Issue를 생성합니다
• 브랜치 이름은 Issue 제목을 기준으로 생성합니다

예시: feat/#12 fix/#18

• 작업 완료 후 본인 이슈 브랜치에서 main 브랜치로 Pull Request(PR)를 생성합니다
• PR 생성 시:
  • 리뷰어에 팀원 전원 추가
  • 최소 1명 이상 코드 리뷰 후 merge
• 서로의 PR에 대해 적극적으로 코드 리뷰를 진행합니다

---

2. Commit Message 규칙 (필수)

• 커밋 메시지는 반드시 정해진 규칙을 따릅니다
• ESLint / Conventional Commit 규칙을 무조건 준수해야 합니다
• 규칙을 준수하지 않으면 막힙니다

Commit Message 형식: type: subject

Type 목록:

• feat: 새로운 기능 추가
• fix: 버그 수정
• docs: 문서 수정
• style: 코드 포맷팅 (로직 변경 없음)
• refactor: 코드 리팩토링
• test: 테스트 코드 추가/수정
• chore: 빌드 설정, 패키지 관리 등

Commit Message 예시: feat: 케이크 커스터마이징 UI 구현
fix: 로그인 유효성 검사 오류 수정
chore: eslint 규칙 업데이트

아래와 같은 커밋 메시지는 사용하지 않습니다.

• 수정
• 버그
• 작업중
• final

---

3. 패키지 추가 시 공유 사항

• 개발 중 새로운 패키지를 추가한 경우 반드시 공유합니다.
• 공유 방법:
  • PR 설명에 아래 항목을 포함합니다.

예시: 추가된 패키지

• react-hook-form
  사용 이유: 폼 상태 관리 및 유효성 검사 단순화
• 불필요한 패키지 추가는 지양합니다
• 공통적으로 영향을 주는 패키지는 사전 공유 후 추가를 권장합니다