Conventional Commits는 깃 커밋 메시지를 작성할 때 일관된 형식을 유지하는 규칙입니다.
이는 협업 시 코드 변경 사항을 쉽게 추적하고, 자동화된 릴리즈 관리(예: semantic-release)를 할 수 있도록 도와줍니다.
커밋 메시지는 다음과 같은 형식을 따릅니다:
<type>(<scope>): <subject>
<type> → 커밋의 유형을 나타냅니다.<scope> → 변경된 코드의 범위를 명시적으로 나타냅니다. (선택 사항)<subject> → 변경 내용을 간결하게 설명합니다.feat(auth): 로그인 기능 추가
fix(cart): 장바구니 총합 계산 오류 수정
docs(readme): 사용법 섹션 추가
| 타입 | 설명 |
|---|---|
feat | 새로운 기능 추가 |
fix | 버그 수정 |
docs | 문서 변경 (코드 변경 없음) |
style | 코드 스타일 수정 (예: 세미콜론 추가, 들여쓰기 변경) |
refactor | 코드 리팩토링 (기능 변경 없음) |
perf | 성능 개선 |
test | 테스트 코드 추가 또는 수정 |
build | 빌드 관련 변경 (예: 패키지 업데이트) |
ci | CI/CD 설정 변경 (예: GitHub Actions, Docker 설정 수정) |
chore | 기타 변경 (예: 린트 설정, 패키지 매니저 변경) |
revert | 이전 커밋 되돌리기 |
<scope> (선택 사항)feat(auth): 소셜 로그인 기능 추가
fix(ui): 버튼 클릭 시 반응 안 하는 문제 수정
refactor(database): 쿼리 최적화<subject> (변경 내용)Add, Fix, Change 대신 add, fix, change 사용).)를 붙이지 않음✔ 올바른 예시
feat(payment): 결제 모듈 추가
fix(api): 사용자 조회 시 null 값 오류 수정
✖ 잘못된 예시
feat: 결제 모듈을 추가했습니다. # 마침표 X
fix(api): 사용자 조회 시 Null 값 오류 수정 # 대문자 X
복잡한 변경 사항일 경우 본문(body)과 푸터(footer)를 추가할 수 있습니다.
- 또는 * 기호를 사용하여 가독성을 높일 수 있음BREAKING CHANGE: 하위 호환이 깨지는 변경 사항을 설명Closes 또는 Fixes: 특정 이슈를 닫을 때 사용feat(user): 회원가입 시 이메일 검증 추가
- 회원가입 시 이메일을 필수로 입력하도록 변경
- 이메일 형식이 맞지 않으면 오류 반환
BREAKING CHANGE: 기존 회원가입 API 응답 구조가 변경됨
fix(login): 로그인 시 예외 처리 추가
- 비밀번호가 틀렸을 경우 명확한 에러 메시지를 반환
- 로그인 시 응답 속도를 개선
Closes #123
✅ 일관성 유지: 프로젝트 팀원들이 동일한 규칙을 따르므로, 커밋 메시지가 일관됨
✅ 자동화 가능: semantic-release 같은 툴을 이용해 버전 자동 관리 가능
✅ CHANGELOG 자동 생성: 커밋 로그를 기반으로 변경 사항을 자동으로 문서화
✅ 쉽게 히스토리 탐색: git log --grep="feat"처럼 특정 타입만 필터링 가능
git commit -m "feat(cart): 장바구니 아이템 삭제 기능 추가"
git commit -m "fix(ui): 다크 모드에서 버튼이 안 보이는 문제 해결"
git commit -m "chore(deps): lodash 최신 버전으로 업데이트"
Conventional Commits 규칙을 따르면 버전 관리가 체계적으로 이루어지고,
나중에 커밋 히스토리를 분석할 때 어떤 변경이 이루어졌는지 쉽게 파악할 수 있습니다.
팀 협업 시에도 강력한 가이드라인이 될 수 있으므로 적극적으로 활용해 보시길 추천합니다! 🚀