반응형
협업하면서 다른 분들이 merge할 때마다의 로그를 보면서
git commit 메시지를 의미있게 써보고 싶었다.
커밋 메시지 쓰는 일반적인 형태를 정리하고자 하는 글이다.
git commit 메시지는 코드 변경 내역을 명확히 기록하기 위한 중요한 수단이다!!
협업이나 나중에 코드를 되돌아볼 때 매우 유용하므로, 일관성 있고 의미 있는 작성 방식을 갖추고 협업을 진행하자
📌 커밋 타입 (Conventional Commits 기반)
타입 설명
| feat | 새로운 기능 추가 |
| fix | 버그 수정 |
| docs | 문서 수정 (README 등) |
| style | 코드 포맷팅, 세미콜론 누락 등 (논리 변경 없음) |
| refactor | 코드 리팩토링 (기능 변경 없음) |
| perf | 성능 개선 |
| test | 테스트 코드 추가/수정 |
| build | 빌드 시스템 관련 변경 (예: webpack 설정) |
| ci | CI 설정 관련 변경 (예: GitHub Actions) |
| chore | 기타 변경사항 (예: 패키지 설치 등) |
| revert | 이전 커밋 되돌리기 |
기본 구조
<타입>: <변경 요약> ← 제목 (50자 이내, 대문자 없이, 마침표 없이)
<본문> ← 선택 사항 (72자 줄바꿈 권장)
예시:
feat: 로그인 기능 추가
사용자로부터 이메일과 비밀번호를 입력받아 JWT를 발급하는 API를 구현했습니다.
bcrypt를 사용한 패스워드 해싱을 포함하며, 에러 처리를 개선했습니다.
✍️ 작성 규칙 요약
- 제목은 50자 이내, 마침표 없이, 동사 원형 사용 (Add ❌ → add ✅)
- 본문은 필요 시 작성, 왜 이런 변경을 했는지 설명
- 영문을 권장하지만, 팀 문화에 따라 한글도 무방
- 하나의 커밋에는 의미 있는 하나의 변경사항만 포함하는 것이 좋음
🛠 추천 커밋 메시지 예시
feat: 장바구니에 제품 추가 기능 구현
fix: 로그인 시 JWT 토큰 누락 오류 수정
docs: README에 프로젝트 실행 방법 추가
refactor: product 컴포넌트 로직 분리
style: prettier 적용 및 불필요한 공백 제거
test: 회원가입 유닛 테스트 추가
📚 참고
- 커밋 메시지를 잘 쓰면 git log --oneline으로 봐도 히스토리를 파악하기 쉬워진다.
- PR 제목이나 릴리즈 노트에 그대로 활용 가능함 (나중에 알아보기도 쉽고 정리할때 꿀이다)
- 팀에 commitlint + husky 등을 도입하면 커밋 메시지 강제도 가능하다.