# [[Conventional Commits]]

## 📌 Brief Summary
Conventional Commits는 일관성 있는 코드 히스토리 관리를 위해 지정된 커밋 메시지 작성 표준 규약입니다 [1, 2]. 일반적으로 `type(scope): description`의 구조를 가지며, 코드에 어떤 변경이 발생했고 그 이유가 무엇인지를 명확히 전달하는 데 목적이 있습니다 [1, 2]. 이 표준을 적용하면 코드의 변경 내역을 쉽게 훑어볼 수 있는(scannable) 히스토리를 구성할 수 있으며, 릴리즈 노트 작성의 자동화를 가능하게 합니다 [1].

## 📖 Core Content
- **기본 포맷**: 커밋 메시지는 `type(scope): description`의 형식을 엄격하게 따릅니다 [1].
- **주요 커밋 타입(Types)** [1, 2]:
  - `feat`: 새로운 기능의 추가
  - `fix`: 버그 수정
  - `docs`: 문서 관련 변경 사항
  - `style`: 코드 스타일 변경 (포맷팅 등 기능에 영향을 주지 않는 변경)
  - `refactor`: 버그 수정이나 새로운 기능 추가를 포함하지 않는 코드 리팩토링
  - `test`: 테스트 코드의 추가 또는 업데이트
  - `chore`: 유지보수 작업 등 기타 작업
- **작성 원칙**:
  - 커밋 메시지는 코드의 '무엇(what)'이 '왜(why)' 변경되었는지 명확하게 설명해야 합니다 [2].
  - 커밋은 작고(small) 논리적인 단위로 의미 있게(meaningful) 작성되어야 합니다 [3, 4]. (예: `fix: handle null response in login API` [4] 또는 `feat: add login form` [3])
- **도입 효과**:
  - 소규모 팀의 기능 브랜치(feature-branch) 워크플로우에서 적용 시 변경 사항 파악이 쉬워지고 코드 리뷰가 단순해집니다 [3, 4].
  - 릴리즈 노트 생성을 자동화할 수 있으며, 팀원 누구나 프로젝트 히스토리를 직관적으로 이해할 수 있게 돕습니다 [1].

## 🔗 Knowledge Connections
- **Related Topics:** [[Git Workflow]], [[Branching Strategies]], [[Code Review]], [[Clean Code Principles]]
- **Projects/Contexts:** [[Team Collaboration]], [[Engineering Scalable Frontend Systems]], [[Version Control]]
- **Contradictions/Notes:** 소스 간의 모순점은 발견되지 않았으며, 소규모 팀 워크플로우부터 대규모 프론트엔드 시스템 아키텍처까지 공통으로 일관된 커밋 명명 규칙(Conventional Commits) 사용을 적극 권장하고 있습니다.

---
*Last updated: 2026-04-26*