📁프로젝트 구조

---

1. assets
   • 이미지 또는 폰트 파일들이 저장되는 곳 (컴포넌트 내부에서 사용 시)
2. components
   • 재사용 가능한 컴포넌트들이 위치하는 폴더, 많아질 시 하위 폴더 생성 후 구분
3. constants
   • 공통적으로 사용되는 상수들을 모아두는 폴더
4. styles
   • css 파일들을 모아두는 폴더 (css 는 어떻게 관리할 것인지 추후 결정)
5. hooks
   • 커스텀 훅 모아두는 폴더 (커스텀 훅을 만들어서 쓸 지 안쓸 지도 개발하면서 결정)
6. pages
   • 라우팅을 적용하는 페이지 컴포넌트들을 모아두는 폴더
7. api
   • api 관련 로직 모듈 파일 및 auth 와 같은 인증 파일 모아두는 폴더.
8. context or store
   • 이 부분은 redux** 나 Context API 사용 시 쓸건데 추후 결정! (전역 상태 관리).

📈Git Flow

1. PR (Pull Request)

• 기본적으로 PR 에서는 어떤 내용을 개발하여 올렸는지 개발 코드에 대한 설명이 작성이 되어야한다.
• Hotfix 나 긴급한 이슈를 제외하고 PR 후 코드리뷰를 안한 후, Merge 에 대한 책임은 본인이 져야한다.

2. Merge

• Merge 시에는 팀원 간의 상의 후 반영을 해야한다. (PR 하고 Merge 하는거라 PR 하고 연결됩니다 !)

3. Branch

• push 와 commit 을 절대적으로 구분을 해서 사용해야한다. -> 안그러면 나중에 git 충돌이 나서 해결하기 힘들어집니다..
• develop (1) 개발 서버에 올릴 수 있는 수준만 Merge 합니다. (2) Merge 할 때도 리뷰는 꼭 거쳐서 진행해야합니다.
• feature (1) Feature 브랜치는 기능 단위로 사용을 해야합니다. (2) feature/기능 이런식으로 사용을 합니다. (예를 들어, 로그인 기능이면 feature/로그인 이런 식입니다.)
• hotfix (1) Hotfix 브랜치는 빠르게 고쳐야 할 문제가 있으면 사용을 합니다. (2) Hotfix 브랜치는 반드시 하나씩 해야합니다. (해결되지 않은 Hotfix 가 있으면 해결 후 올립니다.)

---

Git 커밋 메시지 규칙

• 아래 규칙은 [블로그 참조][https://velog.io/@chojs28/Git-%EC%BB%A4%EB%B0%8B-%EB%A9%94%EC%8B%9C%EC%A7%80-%EA%B7%9C%EC%B9%99]

Type

• feat: 새로운 기능 추가.
• fix: 버그 수정.
• refactor: 코드 리팩토링 (기능 변경 없음).
• style: 코드 스타일 수정 (세미콜론, 들여쓰기).
• docs: 문서 추가/수정.
• test: 테스트 코드 추가/수정.
• chore: 기타 작업 (빌드, 패키지 관리 등).
• perf: 성능 개선.
• ci: CI/CD 관련 설정 및 스크립트 수정.