Git 커밋 메시지 작성 가이드 - Conventional Commits 표준

간단 버전

Git 커밋 메시지를 작성해 주세요.

- 변경 내용: {{변경_내용}}
- 변경 파일: {{변경_파일}}

Conventional Commits 형식으로 작성하세요.

입력값 가이드

인풋 필드

[변경_내용]
▼ 텍스트 입력
placeholder: "예: 로그인 기능 구현"
설명: 어떤 변경을 했는지 핵심 내용을 입력해주세요

[변경_파일]
▼ 텍스트 입력
placeholder: "예: LoginForm.tsx, auth.ts"
설명: 수정한 주요 파일명들을 쉼표로 구분해서 입력해주세요

[변경_이유]
▼ 드롭다운 선택 또는 직접 입력
옵션: 사용자 요청, 성능 이슈 해결, 버그 수정, 리팩토링, 보안 강화, 기타
placeholder: "예: 사용자 요청"
설명: 왜 이 변경이 필요했는지 이유를 선택하거나 입력해주세요

[영향_범위]
▼ 텍스트 입력
placeholder: "예: auth"
설명: 변경이 영향을 미치는 모듈이나 영역을 입력해주세요

[관련_이슈]
▼ 텍스트 입력
placeholder: "예: #123, 없음"
설명: 관련된 이슈나 PR 번호를 입력해주세요 (없으면 '없음' 입력)

Type 카테고리

작성 원칙

제목 (Description)

• 50자 내외로 간결하게
• 마침표 제거, 명령조 사용

✅ 좋은 예:
feat: 사용자 프로필 이미지 업로드 기능 추가
fix: 로그인 시 race condition 수정

❌ 나쁜 예:
feat: 기능을 추가했음.
fix: 버그 수정

본문 (Body)

feat(auth): 소셜 로그인 기능 추가

- OAuthProvider 인터페이스 정의
- 각 소셜 플랫폼별 전략 패턴 구현

Closes #123

Footer

BREAKING CHANGE: `user` 객체의 `profile` 필드가 변경되었습니다.

Closes #123  # 이슈 완전히 해결
Fixes #456   # 버그 수정으로 해결

Atomic Commits

하나의 커밋 = 하나의 논리적 변경

❌ 나쁜 예: feat: 인증 기능 추가와 UI 개선
✅ 좋은 예: feat(auth): JWT 기반 로그인 구현

자주 묻는 질문 (FAQ)

Q: Conventional Commits를 사용해야 하는 이유가 무엇인가요?

A: 다음과 같은 이점이 있습니다:

• 자동화: CHANGELOG, 버전 관리 자동 생성 가능
• 가독성: 커밋 목록만으로 변경 내용 파악 가능
• 협업: 팀원들이 변경 사항을 빠르게 이해
• CI/CD: 특정 타입에 따른 자동 배포 파이프라인 구성

Q: 커밋 메시지 제목은 얼마나 길어야 하나요?

A:

• 제목: 50자 이내를 권장합니다 (GitHub에서 잘림 방지)
• 본문: 각 줄 72자 이내로 작성합니다
• 전체: 제목 + 빈 줄 + 본문 + Footer 구조

Q: 여러 기능을 한 번에 커밋해도 되나요?

A: 권장하지 않습니다. Atomic Commit 원칙을 따르세요:

❌ feat: 로그인 기능 추가 및 결제 UI 개선
✅ feat(auth): JWT 기반 로그인 구현
✅ style(payment): 결제 버튼 레이아웃 수정

Q: BREAKING CHANGE는 언제 사용하나요?

A: 기존 API와 호환되지 않는 변경이 있을 때 사용합니다:

feat(api)!: 사용자 응답 구조 변경

BREAKING CHANGE: user.profile이 user.userProfile로 변경됨
마이그레이션 가이드: docs/migration-v2.md 참조