[Github] Commit Message Convention Guide

Git을 사용해 팀 프로젝트를 하다 보면 커밋 메시지 앞에 'feat:', 'fix:' 같은 접두어가 붙는 것을 자주 보셨을 겁니다. 이 접두어들은 단순한 습관이 아니라, 협업과 프로젝트 관리를 획기적으로 개선하는 커밋 메시지 컨벤션 (Commit Message Convention), 그중에서도 Conventional Commits 규칙을 따르는 형식입니다.

이러한 규칙은 커밋이 어떤 종류의 변경을 포함하는지 한눈에 파악하게 해주고, 프로젝트의 이력 관리를 체계화하는 데 도움을 줍니다.

---

💡 왜 커밋 메시지에 접두어를 붙여야 할까?

일관된 커밋 메시지 형식을 사용하면 다음과 같은 이점을 얻을 수 있습니다.

1. 가독성 및 이력 추적 용이: 커밋 로그만 봐도 변경의 성격(기능 추가인지, 버그 수정인지 등)을 즉시 알 수 있습니다.
2. 자동화: Semantic Versioning (유의적 버전 관리)을 기반으로 버전을 자동으로 올리거나, 변경 사항(Changelog) 문서를 자동으로 생성할 수 있습니다.
3. 협업 효율 증대: 다른 팀원이 어떤 작업을 했는지, Pull Request (PR)의 목적이 무엇인지 빠르게 이해할 수 있습니다.

---

Conventional Commits: 핵심 타입 (접두어) 정리

커밋 메시지의 접두어는 변경의 종류를 나타내는 타입(Type)이며, 일반적으로 다음과 같은 형식을 따릅니다.

<타입>([스코프]): <제목>

가장 널리 사용되는 핵심 타입들을 정리했습니다.

타입 (Type)	용도 및 의미	예시
feat	새로운 기능 (Feature)을 추가했을 때	feat: 사용자 로그인 기능 구현
fix	버그 (Bug)를 수정했을 때	fix: 폼 제출 시 유효성 검사 오류 수정
docs	문서 (Documentation) 관련 변경만 있을 때	docs: API 명세서 업데이트
style	코드의 스타일이나 포맷팅만 변경했을 때 (세미콜론, 공백, 포맷 등, 코드 동작에 영향 없음)	style: 코드 인덴트(들여쓰기) 수정
refactor	리팩토링 (코드 개선, 기능 변경이나 버그 수정 없이 구조만 변경)	refactor: 중복 로직을 헬퍼 함수로 분리
test	테스트 코드를 추가하거나 수정했을 때	test: 회원가입 테스트 케이스 추가
chore	빌드 프로세스, 패키지 관리자 설정 등 기타 자잘한 관리성 변경 (제품 코드와 무관)	chore: 패키지 의존성 버전 업데이트
perf	성능 개선 (Performance Improvement) 관련 변경이 있을 때	perf: 쿼리 속도 최적화
build	빌드 시스템이나 외부 종속성 관련 변경	build: Webpack 설정 파일 수정
ci	CI (지속적 통합) 설정 파일 관련 변경	ci: GitLab CI 파이프라인 설정 추가
revert	이전 커밋을 되돌릴 때	revert: 이전에 커밋했던 A 기능 롤백

🔍 커밋 메시지 작성 팁

좋은 커밋 메시지는 단순히 규칙을 따르는 것을 넘어, 프로젝트의 스토리를 명확하게 전달해야 합니다.

1. 제목(Subject)은 간결하게: 제목은 50자를 넘기지 않도록 간결하게 작성합니다.
2. 명령형 사용: 마치 "이렇게 변경하세요"라는 명령조로 작성하는 것이 일반적입니다. (예: Add feature 대신 add feature)
3. 본문(Body)은 선택 사항이지만 중요: 변경의 이유나 자세한 내용이 필요하다면 본문 영역에 "무엇을, 왜" 변경했는지 상세히 설명합니다.

---

Happy GoSu ~

WooGong ))*

//////////////////////////////////////