브랜치 전략
- dev: 모든 PR을 합치는 기본 브랜치
- release: 릴리즈 노트 발행
- main: 릴리즈 이후 머지
브랜치 네이밍 예시
분류/이슈번호-이슈요약
예) refactor/33-login, feat/12-search
커밋 컨벤션
chore: 기타 유지보수 작업(환경 설정, 잡일 등)
feat: 새로운 기능 추가
fix: 버그수정
refactor: 코드 리팩토링
test: 테스트 코드
docs: 문서 수정
styles: 코드 스타일 변경(세미콜론, 포맷팅 등), 기능 변경 없음
design: CSS 등 UI 스타일 변경
분류: 요약 (#이슈번호)
- 자세한 변경
- 의도
ex) feat: 로그인 (#123)
Merge 규칙
- 3명의 코드 리뷰 & Approve가 있어야지 Merge 가능
- 모든 Merge는 기본 Merge 방식 사용
코딩 컨벤션
백엔드 코딩 컨벤션
| 항목 |
규칙 |
| 언어 |
TypeScript (NestJS) |
| 네이밍 |
camelCase (함수/변수), PascalCase (클래스), snake_case (DB 컬럼) |
| 소스 코드 파일 |
camelCase (예: bookingService.ts) |
| 문서 파일 |
kebab-case (모두 소문자, 단어 사이 -) (예: app-design.md) |
| 주석 |
함수 상단 JSDoc 형식 사용 (/** ... */) |
| DB 키워드 |
전부 소문자, 예약어 피하기 (user → users) |
| 모듈명 |
단수형 |
| 테스트 폴더 |
test, 소스코드와 같은 위치(설명서처럼) |
| 테스트 파일 |
.spec.ts, .e2e-spec |
프론트엔드 코딩 컨벤션
| 항목 |
규칙 |
| 언어 |
TypeScript (React) |
| 코드 파일 |
PascalCase (페이지, 컴포넌트, 스타일), camelCase (그 외 나머지 함수 등) |
| 폴더명 |
kebab-case / 복수형 |
네이밍 규칙