커밋 메시지 컨벤션

Conventional Commits 기반 실무 적용 가이드

기본 형식 (표준)

좋은 예시

Type 종류 (가장 중요)

타입	의미	예시
feat	새로운 기능 추가	feat: 게시글 작성 기능
fix	버그 수정	fix: 로그인 오류 수정
docs	문서 변경	docs: README 수정
style	코드 스타일 (포맷, 세미콜론 등)	style: 포맷 정리
refactor	리팩토링 (기능 변화 없음)	refactor: 서비스 계층 분리
test	테스트 코드	test: UserService 테스트 추가
chore	기타 작업 (빌드, 설정 등)	chore: gradle 설정 변경
build	빌드 시스템, 의존성	build: 의존성 버전 업
ci	CI 설정	ci: GitHub Actions 추가
perf	성능 개선	perf: 쿼리 최적화
revert	커밋 되돌리기	revert: 잘못된 커밋 취소

Subject 작성 규칙

•

50자 이내로 간결하게

•

명령형, 현재형 사용 (과거형 )

•

마침표 사용하지 않기

•

첫 글자는 소문자 (영문 기준)

나쁜 예

좋은 예

Scope (선택사항)

변경 사항이 영향을 미치는 범위/모듈을 명시합니다.

Scope 예시: auth, user, admin, db, api, ui, core, config 등

Body (본문, 선택사항)

무엇을, 왜 변경했는지 상세하게 설명합니다.

Footer (푸터, 선택사항)

이슈 트래커와 연동하거나 Breaking Change를 명시합니다.

이슈 연동

Breaking Change

한글 vs 영어?

한글 사용 가능! (팀 내 합의가 가장 중요)

한글 사용

•

읽기 쉽고 이해가 빠름

•

한국 팀에 적합

영어 사용

•

국제 협업에 유리

•

오픈소스 기여 시 필수

실무용 추천 컨벤션

개인 / 소규모 팀

→ Type만 명확히, Scope는 생략 가능

중대형 팀 / 기업

→ Scope 필수, 모듈별 관리 명확

오픈소스

→ 영어 사용, 이슈 연동, Breaking Change 명시

실무 커밋 예시 모음

프론트엔드

백엔드

테스트

인프라 / DevOps

문서

실무 팁 (중요)

1. 한 커밋 = 한 목적

2. 커밋 메시지만 보고 변경 사항 파악 가능해야 함

3. 자주 커밋하기

4. 커밋 전 리뷰하기

5. Breaking Change는 반드시 명시

한 줄 요약

커밋 메시지는 "무엇을 왜 했는지"를 짧고 명확하게 남기는 기록 미래의 나와 팀원을 위한 가장 중요한 문서입니다!

참고 하기

커밋 템플릿 설정하기 (자동화)

Git Hook으로 커밋 규칙 강제하기

IntelliJ / VSCode 커밋 메시지 플러그인 사용

Commitizen 설치 (대화형 커밋 도구)

팀 커밋 컨벤션 문서화 및 공유

참고 자료

•

Conventional Commits 공식 사이트

•

Angular Commit Guidelines

•

How to Write Better Git Commit Messages