Conventional Commits의 타입 정리
💡 참고: https://www.conventionalcommits.org/en/v1.0.0/ Conventional Commits에서 사용되는 주요 타입을 정리하면 다음과 같습니다. 각 타입은 커밋의 목적을 명확하게 하기 위해 사용됩니다. 1. (Feature, 기능 추가)새로운 기…
💡 참고: https://www.conventionalcommits.org/en/v1.0.0/
Conventional Commits에서 사용되는 주요 타입을 정리하면 다음과 같습니다. 각 타입은 커밋의 목적을 명확하게 하기 위해 사용됩니다.
1. feat (Feature, 기능 추가)
-
새로운 기능을 추가할 때 사용합니다.
-
Semantic Versioning에서 MINOR 버전 업데이트에 해당합니다.
-
예시:
feat: 사용자 프로필 페이지 추가
feat(auth): 소셜 로그인 기능 구현2. fix (Bug Fix, 버그 수정)
-
버그를 수정할 때 사용합니다.
-
Semantic Versioning에서 PATCH 버전 업데이트에 해당합니다.
-
예시:
fix: 로그인 오류 수정
fix(api): 응답 데이터가 null일 때 발생하는 예외 처리3. docs (Documentation, 문서 수정)
-
문서 관련 변경 사항을 기록할 때 사용합니다.
-
코드 수정 없이 README, 주석, API 문서 등을 변경할 때 사용합니다.
-
예시:
docs: README에 설치 방법 추가
docs(guide): API 사용 예제 수정4. style (Styling, 코드 스타일 변경)
-
코드의 의미에는 영향을 주지 않는 코드 스타일 변경에 사용합니다.
-
예: 코드 포맷팅, 공백 추가/제거, 세미콜론 변경 등
-
예시:
style: 코드 정리 및 불필요한 공백 제거
style(css): 버튼 테두리 스타일 변경5. refactor (Refactoring, 코드 리팩토링)
-
기존 기능을 변경하지 않고 코드 구조를 개선할 때 사용합니다.
-
성능 최적화, 중복 코드 제거 등이 포함됩니다.
-
예시:
refactor: 데이터베이스 쿼리 최적화
refactor(component): useEffect 정리 및 상태 관리 개선6. perf (Performance, 성능 개선)
-
성능을 개선할 때 사용합니다.
-
실행 속도 최적화, 메모리 사용량 감소 등의 변경을 포함합니다.
-
예시:
perf: 이미지 로딩 최적화
perf(query): API 요청 횟수 줄이도록 개선7. test (Testing, 테스트 코드 추가/수정)
-
테스트 코드 추가, 변경, 보완 시 사용합니다.
-
유닛 테스트, 통합 테스트 등을 포함합니다.
-
예시:
test: 로그인 유닛 테스트 추가
test(utils): 날짜 변환 함수 테스트 코드 작성8. build (Build, 빌드 관련 변경)
-
빌드 시스템, 패키지 매니저 설정 변경 시 사용합니다.
-
예시:
build: Webpack 설정 최적화
build(deps): lodash 패키지 업데이트9. ci (Continuous Integration, CI 관련 변경)
-
CI/CD 파이프라인 설정 변경 시 사용합니다.
-
GitHub Actions, Jenkins, Travis 등의 설정 변경이 포함됩니다.
-
예시:
ci: GitHub Actions 캐싱 추가
ci(travis): Node.js 18 버전 추가 지원10. chore (Chore, 기타 변경 사항)
-
코드 수정 없이 빌드 프로세스, 패키지, 환경 설정 등의 변경에 사용합니다.
-
예시:
chore: ESLint 규칙 수정
chore(deps): 패키지 종속성 업데이트11. revert (Revert, 이전 커밋 되돌리기)
-
이전 커밋을 되돌릴 때 사용합니다.
-
일반적으로
git revert명령어와 함께 사용됩니다. -
예시:
revert: 잘못된 커밋을 되돌림
revert: feat(auth): 소셜 로그인 기능 제거12. BREAKING CHANGE (중대한 변경 사항)
-
API 변경 등 이전 버전과 호환되지 않는 변경 사항을 포함할 때 사용합니다.
-
feat!또는fix!처럼 느낌표(!)를 추가하거나, 본문 또는 꼬리말에BREAKING CHANGE:를 포함할 수 있습니다. -
예시:
feat!: 기존 인증 방식을 JWT에서 OAuth로 변경
BREAKING CHANGE: 사용자 인증 방식이 변경되었으며, 기존 JWT 토큰이 더 이상 유효하지 않습니다.정리된 Conventional Commits 타입
| 타입 | 설명 |
|
feat |
새로운 기능 추가 |
|
fix |
버그 수정 |
|
docs |
문서 수정 (README, 주석 등) |
|
style |
코드 스타일 변경 (공백, 세미콜론 등) |
|
refactor |
코드 리팩토링 (기능 변경 없음) |
|
perf |
성능 개선 |
|
test |
테스트 코드 추가/수정 |
|
build |
빌드 관련 변경 |
|
ci |
CI/CD 설정 변경 |
|
chore |
기타 유지보수 작업 (패키지 업데이트 등) |
|
revert |
이전 커밋 되돌리기 |
|
BREAKING CHANGE |
주요 변경 사항 포함 (기존 코드와 호환되지 않음) |
이 규칙을 따르면 체계적인 커밋 메시지 작성이 가능하며, 자동화 도구와 연동하여 버전 관리 및 배포 프로세스를 쉽게 관리할 수 있습니다. 🚀