@@ -17,12 +17,14 @@ Spring Boot 기반의 백엔드 서버입니다.
1717
1818## ⚙️ 로컬 개발 환경 설정
1919
20- ### 1. GitHub 저장소 클론
20+ ### 1. GitHub 저장소 클론 및 npm 패키지 설치
2121
2222``` bash
2323git clone https://github.com/your-id/saerok-BE.git
2424cd saerok-BE
25+ npm install # 커밋 컨벤션 강제를 위한 도구 설치
2526```
27+ npm 명령어 실행이 안 될 경우 Node.js를 먼저 설치해야 합니다.
2628
2729### 2. IntelliJ에서 프로젝트 열기
2830
@@ -83,9 +85,134 @@ DB_PASSWORD=your_password
8385
8486---
8587
86- ## 📌 커밋 메시지 컨벤션 (임시)
88+ # 📝 커밋 컨벤션 가이드
8789
88- - ` feat ` : 기능 추가
89- - ` fix ` : 버그 수정
90- - ` chore ` : 설정, 환경, 빌드 관련 변경
90+ 우리 팀은 커밋 메시지의 일관성과 가독성을 위해 ** Conventional Commit** 기반 커밋 컨벤션을 사용합니다.
91+ 아래 가이드를 참고하여 다음 두 가지 방법 중 하나로 커밋 메시지를 작성할 수 있습니다.
9192
93+ ---
94+
95+ ## 🛠 커밋 작성 방법
96+
97+ ### 1. 스스로 커밋 메시지 작성
98+ 직접 커밋 메시지를 입력하는 방식입니다. 커밋 컨벤션에 익숙할 경우 이 방법이 더 빠릅니다.
99+
100+ - 터미널에서 직접 입력:
101+ ` Alt + F12 ` → ` git commit -m "type(scope): subject" `
102+
103+ - IntelliJ Git 툴 창에서 커밋 메시지 작성 후 Commit
104+
105+ ※ 이 경우에도 메시지가 컨벤션을 어기면 커밋이 거부됩니다.
106+
107+ ### 2. 프롬프트를 통해 커밋 메시지 작성
108+ 질문에 답하면서 커밋 메시지가 자동으로 완성되는 방식입니다.
109+
110+ - 터미널에서 실행:
111+ ` Alt + F12 ` → ` npm run commit ` 또는 ` npx cz `
112+
113+ > 이 방법은 커밋 컨벤션을 자동으로 따를 수 있어 실수 없이 작성할 수 있습니다.
114+
115+ ---
116+
117+ ## ✅ 커밋 메시지 형식
118+
119+ ```
120+ <type>(<scope>): <subject>
121+ <BLANK LINE>
122+ <body>
123+ ```
124+
125+ > ` footer ` 는 현재 사용하지 않습니다.
126+
127+ ### 🔍 커밋 예시
128+
129+ ``` bash
130+ feat(user): 회원가입 시 이메일 중복 확인 기능 추가
131+ ```
132+
133+ ``` bash
134+ chore(infra): commitlint + husky 설정 추가
135+
136+ 팀 전체 커밋 메시지 규칙 강제 적용을 위해 설정.
137+ pre-commit 훅으로 lint 검사도 함께 수행.
138+ ```
139+
140+ ``` bash
141+ refactor(entity): Collection 엔티티 구조 개선
142+
143+ isTemporary 필드 제거 및 공개 여부 필드 추가.
144+ 불필요한 데이터 제거로 구조 단순화.
145+ ```
146+
147+ ---
148+
149+ ## 1. type (무엇을 했는가)
150+
151+ | 타입 | 설명 |
152+ | ------| ------|
153+ | ✨ ` feat ` | 새로운 기능 추가 |
154+ | 🐛 ` fix ` | 버그 수정 |
155+ | 📚 ` docs ` | 문서 관련 변경 (예: README, 주석) |
156+ | 💎 ` style ` | 코드 의미에는 영향을 주지 않는 스타일 변경 (포맷, 세미콜론 등) |
157+ | 📦 ` refactor ` | 리팩토링 (기능 변경 없이 구조 개선) |
158+ | 🚀 ` perf ` | 성능 개선 |
159+ | 🚨 ` test ` | 테스트 코드 추가/보완 |
160+ | ⚙️ ` ci ` | CI 설정 및 관련 스크립트 변경 |
161+ | ♻️ ` chore ` | 기타 작업 (예: 패키지 설치, 설정 파일 변경, 디렉토리 정리 등) |
162+ | 🗑 ` revert ` | 이전 커밋 되돌리기 |
163+
164+ ---
165+
166+ ## 2. scope (어디를 바꿨는가)
167+
168+ | 스코프 | 설명 |
169+ | --------| ------|
170+ | 🙋♂️ ` user ` | 사용자 기능 (로그인, 프로필 수정 등) |
171+ | 📘 ` dex ` | 도감 기능 (새 목록 조회, 새 스크랩 등) |
172+ | 🗂️ ` coll ` | 컬렉션 기능 (등록, 수정 등) |
173+ | 🗺️ ` map ` | 지도 기능 (위치 기반 조회 등) |
174+ | 🏗️ ` entity ` | 엔티티 구조 변경 (필드 추가, 매핑 수정 등) |
175+ | 🛠️ ` infra ` | 설정/인프라 변경 (스크립트, .env, husky, commitlint 등) |
176+
177+ ✅ 범위 지정이 어렵거나 필요 없을 경우 ` scope ` 는 생략 가능합니다.
178+
179+ ---
180+
181+ ## 3. subject (무슨 일이 일어났는가)
182+
183+ - ** 한 줄 요약** 으로 변경 내용을 간결하게 작성합니다.
184+ - 원활한 소통을 위해 한국어로 작성합니다.
185+ - 마침표(.)는 붙이지 않습니다.
186+
187+ > 예: ` 로그인 오류 수정 ` , ` 컬렉션 정렬 기능 추가 ` , ` CI 워크플로 최적화 `
188+
189+ ---
190+
191+ ## 4. body (왜 그렇게 했는가)
192+
193+ - 선택 사항이지만 ** 기능 수정/리팩토링 등 복잡한 변경에는 작성 권장**
194+ - "무엇을 바꿨고, 왜 바꿨는지"에 집중해서 작성하세요.
195+
196+ > 예:
197+ > 컬렉션 목록이 정렬되지 않아 UX 저하 발생.
198+ > createdAt 기준 내림차순 정렬 적용.
199+
200+ ---
201+
202+ ## 🛡 유효성 검사 규칙 요약
203+
204+ 커밋 컨벤션 규칙은 ` commitlint.config.js ` 에 의해 설정됩니다.
205+
206+ | 항목 | 규칙 |
207+ | ------| ------|
208+ | type | 반드시 ` type-enum ` 목록 내에서 선택해야 함 |
209+ | scope | 반드시 ` scope-enum ` 목록 내에서 선택하거나 생략 가능 (` empty ` ) |
210+ | footer | 항상 비워야 함 (` BREAKING CHANGE ` , ` Issue ` 등 사용하지 않음) |
211+
212+ ---
213+
214+ ## 📌 참고
215+
216+ - 커밋 컨벤션 강제는 ` husky ` , ` commitlint ` , ` commitizen ` 등의 도구로 구성되어 있습니다.
217+
218+ ---
0 commit comments