커밋 메시지 규칙 스크립트 추가 및 가이드 정리

커밋 메시지 규칙 검증 스크립트를 추가하고 가이드를 정리한다.

제목 50자, 본문 72자, 빈 줄, 광고 금지 규칙을 준수한다.
This commit is contained in:
2025-12-01 10:48:39 +09:00
parent 2740522f05
commit ede2dc201c
2 changed files with 86 additions and 49 deletions

View File

@@ -1,52 +1,18 @@
질문에 대한 답변과 설명은 한국어로 한다.
### 커밋 메시지 구성
## Quality Assurance Guidelines
```
<type>[optional scope]: <description>
[optional body]
[optional footer(s)]
```
### 타입 목록
다음 타입 키워드 중 하나를 사용해야 합니다:
- `feat`: 새로운 기능 추가
- `fix`: 버그 수정
- `docs`: 문서 변경 (코드 변경 없음)
- `style`: 포매팅, 세미콜론 누락 등 기능/로직 무관한 변경
- `refactor`: 코드 리팩토링 (기능 변화 없음)
- `perf`: 성능 개선
- `test`: 테스트 코드 추가/수정
- `build`: 빌드 시스템 또는 외부 의존성 관련 변경
- `ci`: CI 설정 관련 변경
- `chore`: 기타 잡무성 변경
- `revert`: 이전 커밋 되돌리기
### 예시
```
feat(auth): 로그인 기능 추가
fix(api): 인증 헤더 누락 문제 수정
docs(readme): 사용법 예제 추가
refactor(user): useEffect 내부 로직 리팩토링
```
### 본문 작성 규칙
- `왜` 변경되었는지 설명 (가능하면)
- `무엇`이 변경되었는지를 간결하게 기술
- 줄바꿈 후 자세한 설명 가능
---
## 기타
- 긴 커밋 메시지 제목은 줄이지 말고 의도를 명확히 표현
- 린트나 릴리즈 자동화 도구에서 Conventional Commits를 기대할 수 있음
### Commit Standards
1. Write in Korean.
2. Use the present tense in the subject line (e.g., "Add feature" not "Added feature").
3. Keep the subject line to 50 characters or less.
4. Add a blank line between the subject and body.
5. Keep the body to 72 characters or less per line.
6. Within a paragraph, only break lines when the text exceeds 72 characters.
7. Describe changes to public API features and do not include implementation details such as package-private code.
8. Do not mention test code in commit messages.
9. Do not use any prefix (such as "fix:", "update:", "docs:", "feat:", etc.) in the subject line.
10. Do not start the subject line with a lowercase letter unless the first word is a function name or another identifier that is conventionally lowercase and there is a clear, justifiable reason for the exception. Otherwise, always start with an uppercase letter.
11. Do not include tool advertisements, branding, or promotional content in commit messages.
12. Use separate git commands to stage files before committing.
13. Always validate commits using `work/scripts/check-commit-message-rules.sh` and fix until validation passes.