Conventional Commits는 커밋 메시지를 일관되고 의미 있는 방식으로 작성하기 위한 규약입니다. 이 규약을 사용하면 자동화 도구를 통해 버전 번호를 생성하거나 변경 로그를 자동으로 업데이트하는 데 유용합니다. 다음은 Conventional Commits의 주요 커밋 유형과 예시입니다.
1. feat (Features)
새로운 기능을 추가할 때 사용합니다.
feat: allow provided config object to extend other configs
2. fix (Bug Fixes)
버그를 수정할 때 사용합니다.
fix: correct minor typos in code
3. docs (Documentation)
문서만 변경했을 때 사용합니다.
docs: update README with new integration information
4. style (Styles)
코드 의미에 영향을 주지 않는 변경사항(공백, 포맷팅, 세미콜론 누락 등)에 사용합니다.
style: format code according to company style guidelines
5. refactor (Code Refactoring)
버그를 수정하거나 기능을 추가하지 않는 코드 변경사항에 사용합니다.
refactor: simplify calculation function
6. perf (Performance Improvements)
성능을 향상시키는 코드 변경에 사용합니다.
perf: improve parsing speed of large JSON files
7. test (Tests)
테스트를 추가하거나 기존 테스트를 수정했을 때 사용합니다.
test: add tests for new parsing algorithm
8. build (Builds)
빌드 시스템 또는 외부 종속성에 대한 변경사항에 사용합니다.
build: update dependencies to newer versions
9. ci (Continuous Integrations)
CI 구성 파일과 스크립트 변경에 사용합니다.
ci: set up CI service on GitHub Actions
10. chore (Chores)
기타 변경사항에 사용합니다. 대부분은 소스 코드나 테스트 파일들과 직접 관련이 없는 변경사항입니다.
chore: update npm scripts
11. revert (Reverts)
이전 커밋을 되돌릴 때 사용합니다.
revert: revert commit 123a1b2
12. breaking change (Breaking Changes)
API 변경과 같이 호환성을 깨뜨리는 변경사항을 표시할 때 사용합니다. 일반적으로 feat 또는 fix 유형과 함께 BREAKING CHANGE: 푸터를 추가합니다.
feat: change the signature of our public API
BREAKING CHANGE: the function now requires an object as the first argument
이 규약을 따르면 프로젝트의 커밋 로그가 더 읽기 쉽고, 버전 관리 및 릴리스 프로세스를 자동화하기 쉬워집니다. 각 커밋의 목적이 명확해지므로, 다른 개발자들이 프로젝트에 더 쉽게 참여할 수 있습니다.
