[git] Conventional Commits 규칙

Q: 깃에 커밋할때 feat: refactor: chore: fix: docs: 처럼 잘 쓰는 구분 규칙 있어?

A: 응, Conventional Commits라는 널리 쓰이는 규칙이 있어.

주요 타입들

타입	용도
feat	새로운 기능 추가
fix	버그 수정
refactor	기능 변경 없이 코드 구조 개선
chore	빌드, 패키지 매니저 설정 등 (코드 변경 X)
docs	문서 수정 (README 등)
style	코드 포맷팅, 세미콜론 누락 등 (로직 변경 X)
test	테스트 코드 추가/수정
perf	성능 개선
ci	CI/CD 설정 변경
build	빌드 시스템, 외부 의존성 변경
revert	이전 커밋 되돌리기

형식

(): 

[body]

[footer]

예시:

feat(auth): 소셜 로그인 기능 추가
fix(api): 사용자 조회 시 null 에러 수정
refactor(user): 서비스 레이어 분리
chore: eslint 설정 업데이트
docs: API 문서 업데이트

• scope는 선택사항이지만 모듈/기능 단위로 적으면 나중에 히스토리 찾기 편함
• subject는 명령형으로, 50자 이내 권장
• breaking change가 있으면 feat!: 또는 footer에 BREAKING CHANGE: 표기

#git, #버전관리, #conventional_commits, #git규칙, #커밋규칙