Rules | Notion

Code Convention

Naming Convention (이름 규칙):
- 변수, 함수, 컴포넌트: camelCase (e.g., productList, getUserData)
  - 띄어쓰기 x & 첫 단어 첫 글자 소문자 & 첫 단어 이후의 첫 글자 대문자
- 파일 및 폴더: kebab-case (e.g., test-file.js)
  - 공백은 하이픈으로 대체 & 소문자
React Component
- 함수 선언
  - 타입 추론 가능하기 때문
  - function()
- 외부에서 사용하지 않는 컴포넌트는 export x
함수명 작성:
- 동사 + 명사 형태(e.g, getResult)
Husky(feat.Prettier & ESLint):
- 코드 스타일을 자동화하기 위해 Prettier와 ESLint 설정 적용
- (git hook을 활용한) Husky로 commit, push 전 Prettier, ESLint 검사

폴더 및 파일 구조

project-root/
├── public/               # 정적 파일 (이미지, 폰트, etc.)
├── src/                  # 소스 코드
│   ├── components/       # 재사용 가능한 컴포넌트(css 관련 파일도 이 폴더에)
│   │   ├── layout/       # Header, footer, etc.
│   │   ├── common/       # Button, DropDown, etc.
│   ├── pages/            # Next.js 페이지 라우트
│   │   ├── api/          # API 라우트
│   │   ├── auth/         # 인증 관련 페이지 (예: 로그인, 회원가입)
│   │   └── index.tsx     # 메인 페이지
│   │   └── _app.tsx      # 모든 페이지의 공통 설정
│   ├── styles/           # 전역 스타일 또는 컴포넌트 스타일
│   ├── hooks/            # 커스텀 훅
│   ├── contexts/         # Context API 관련 파일
│   ├── lib/              # 유틸리티 함수, API 호출 함수
│   ├── types/            # TypeScript 타입 정의
│   └── store/            # 전역 상태 관리 (Recoil, Redux 등 사용 시)
├── .env.local            # 환경 변수
├── next.config.js        # Next.js 설정 파일
└── tsconfig.json         # TypeScript 설정 파일

https://www.codeit.kr/topics/fe-sprint10-mission/lessons/8612

PR (Pull Request) 규칙

PR 제목과 설명:
- 제목: 간결하게 변경 사항을 설명 (e.g., Feat: "로그인 기능 구현")
- 본문: 어떤 이유로 어떤 변경을 했는지 상세히 작성, 관련 이슈나 참고 자료 첨부
PR 사이즈:
- 작은 단위의 PR을 권장. 하나의 기능이나 버그 수정에 집중.
리뷰어 지정:
- PR 후 디스코드에 멘션해 리뷰 요청
- ~ 12/22(일) 리뷰어 2명 → 12/23(월) 리뷰어 1명
- 리뷰 후 승인을 받아야 머지 가능
Merge Policy:
- 승인 받은 PR은 담당자가 머지
- merge 방식은 기본 설정대로

https://velog.io/@ye-ji/Git-PR-잘-쓰는-방법

Commit Rules

<aside> 💡

Feat	새로운 기능을 추가할 경우
Style	CSS 등 사용자 UI 디자인 변경
Fix	버그를 고친 경우
Refactor	프로덕션 코드 리팩토링
Test	테스트 추가, 테스트 리팩토링 (프로덕션 코드 변경 X)
Rename	파일 혹은 폴더명을 수정하거나 옮기는 작업만인 경우
Remove	파일을 삭제하는 작업만 수행한 경우
!BREAKING CHANGE	커다란 API 변경의 경우
!HOTFIX	급하게 치명적인 버그를 고쳐야하는 경우
Comment	필요한 주석 추가 및 변경
Docs	문서를 수정한 경우
Chore	빌드 테스트 업데이트, 패키지 매니저를 설정하는 경우 (프로덕션 코드 변경 X)
</aside>

참고 자료

Ground Rules

커뮤니케이션:
- 모든 팀원은 (오전 11시) 매일 스탠드업 회의에 참여하여 진행 상황을 공유
- 이슈가 생기면 즉시 팀 채널에 공유
  - 질문, 도움 요청하는 것 주저하지 말기
Git Flow:
- main 브랜치는 항상 배포 가능한 상태 유지
- 새 기능 개발은 feature/이슈번호-기능이름 브랜치에서 작업
  - commit 할 때 branch가 feature/이슈번호-기능이름 인지 확인
  - ex) feature/1-와인상세페이지
- feature → develop → main
  - 기능 작업한 거 올리는 브랜치 feature
  - 프로젝트 과정 중 merge하는 브랜치 develop
    - 합쳤을 때 생기는 오류도 여기서 잡음
    - pull 도 여기서 받음
  - 최종 배포하는 브랜치 main