[GitHub] 효과적인 Git Convention 가이드라인 (한국어 예시)

---

효과적인 Git Convention 가이드라인 (한국어 예시)

GitHub Conventional Commits는 커밋 메시지를 구조화하여 자동화된 버저닝과 변경 로그 생성을 가능하게 하는 표준이다.

---

커밋 메시지 형식

<type>(<scope>): <description>

[optional body]

[optional footer]

---

주요 커밋 타입

타입	설명	예시
feat	사용자를 위한 새로운 기능이나 특성 추가	feat: 사용자 인증 시스템 추가
fix	기존 기능의 오류나 문제 해결	fix: 로그인 유효성 검사 오류 해결
docs	README, API 문서, 주석 등 문서만 변경	docs: API 문서 업데이트
style	공백, 포맷팅, 세미콜론 등 코드 동작에 영향 없는 스타일 변경	style: 컴포넌트 파일 들여쓰기 수정
refactor	기능 변경 없이 코드 구조를 개선	refactor: 사용자 유효성 검사 로직 별도 모듈로 분리
perf	성능을 향상시키는 코드 변경	perf: 지연 로딩으로 이미지 로딩 최적화
test	테스트 코드 추가, 수정, 삭제	test: 인증 서비스 단위 테스트 추가
build	빌드 도구, 의존성, 설정 파일 변경	build: 웹팩 설정 업데이트
ci	GitHub Actions, Travis CI 등 CI/CD 설정 변경	ci: 자동화된 테스트 워크플로우 추가
chore	패키지 매니저 설정, 의존성 업데이트 등 기타 변경사항	chore: 최신 버전으로 의존성 업데이트
design	CSS 등 사용자 UI 디자인 변경	design: 버튼 스타일 업데이트
comment	필요한 주석 추가 및 변경	comment: 복잡한 로직에 대한 설명 주석 추가
rename	파일 또는 폴더명 수정/이동	rename: utils 폴더를 src로 이동
remove	파일을 삭제하는 작업만 수행	remove: 사용되지 않는 컴포넌트 삭제

---

스코프 (Scope)

• 커밋이 영향을 미치는 범위를 명시합니다.
• 예시: auth, user, api, components, ui, utils 등
• 여러 범위에 걸쳐 변경 사항이 있는 경우 *를 사용할 수 있습니다.
  • 예시: feat(*): 전역 검색 기능 구현

---

설명 (Description)

• 현재 시제를 사용합니다. (예: "로그인 기능 추가" 대신 "로그인 기능 추가합니다")
• 첫 글자는 소문자로 시작합니다.
• 마지막에 마침표를 넣지 않습니다.

---

고급 사용법

Breaking Changes (하위 호환성을 깨뜨리는 변경사항)

• 기존 API나 기능의 호환성을 깨뜨리는 커다란 변경의 경우 !와 함께 BREAKING CHANGE 푸터를 사용합니다.
• 예시:
• feat!: API 응답 형식 변경 BREAKING CHANGE: API가 이제 중첩된 객체 구조로 데이터를 반환합니다. 모든 API 호출을 업데이트해야 합니다.

다중 타입 (Multiple Types)

• 단일 커밋에 여러 타입의 변경사항이 포함된 경우, 가장 중요한 타입을 우선으로 작성하고 본문(body)에 상세 내용을 추가하는 것을 고려할 수 있습니다.
• 하지만 가능하면 단일 책임 원칙에 따라 커밋을 분리하는 것이 좋습니다.

---