앞서 Git Flow에 대해 알아보았습니다
가장 중요한 포인트는 역시 협업이었죠
이번에는 commit message convention에 대해 알아보려고 합니다
commit message가 중구난방이면 혹은 팀원들끼리 이야기가 되어있지 않아 팀원들이 알아볼 수 없다면 협업의 툴로써 의미가 조금 퇴색되겠죠?
협업에 알맞도록 유용한 커뮤니케이션을 위하여 우리는 commit message에 어느정도 약속을 정해놓고 사용하는 것이 좋습니다
Commit Message Convention
서두에서 말했지만 조금 더 자세하게 이야기해볼게요
Commit Message Convention을 사용하는 이유
- 변경 내용을 쉽게 확인할 수 있다 (가독성)
- 히스토리 추적에 용이하다
- 목적이 명확해진다
- 자동으로 버전 관리가 가능하다
그러면 대중적으로 사용되는 규칙에 대해 소개해보겠습니다
📑 대표적인 커밋 메세지 규칙
가장 널리 쓰이는 규칙으로
<type>(<scope>): <short description>필요하다면 아래에 바디를 덧붙여
<type>(<scope>): <short description>
<body>이렇게 사용합니다
조금 난해하죠?
우선 type을 정리해볼게요
type
| 타입 | 의미 |
|---|---|
| feat | 새로운 기능 |
| fix | 버그 수정 |
| docs | 문서 수정 |
| style | 코드 포맷/스타일 (기능 변경 없음) |
| refactor | 코드 구조 변경 (기능 변경 없음) |
| perf | 성능 개선 |
| test | 테스트 코드 추가/수정 |
| chore | 기타 변경 (빌드, 설정 등) |
다음으로는 scope입니다
scope
()가 있는 만큼 옵션입니다
예를 들어
feat(auth): 로그인 기능 추가
fix(api): 회원 조회 오류 수정
docs(readme): 설치 가이드 추가이런 식으로 사용됩니다
description (설명)
설명은 짧고, 명확하게 합니다
그리고 현재 시제를 사용합니다
feat: 회원가입 이메일 인증 추가
fix: 비밀번호 입력 오류 처리body(본문)
추가 설명이 필요할 경우 사용됩니다
들어가는 내용으로는
- 왜 이 변경을 했는지
- 어떻게 해결했는지
- 참고 이슈 번호
등을 기입합니다
fix(login): 인증 토큰 만료 오류 수정
JWT 토큰 만료 시 클라이언트가 무한 로딩되는 문제를 해결했다.
토큰 재발급 로직을 추가하여 유저 경험을 개선했다.❗Breaking Change
중대한 변경이 있다면 BREAKING CHANGE:를 명시해요
feat!: API response 포맷 변경
BREAKING CHANGE: user 객체 구조가 바뀌었습니다.정리하자면, 커밋 메세지 컨벤션은 협업을 더 효율적으로 하기 위해 사용되는 만큼 팀 단위로 약속을 정해두는 것입니다
단순히 저장하기 위한 메세지가 아닌 의사소통을 위한 것으로 받아들이면 좋을 것 같아요
끝으로 사용되는 이모지를 첨부할게요! 이건 그냥 꾸미기 용도입니다
Commit Message Emoji
| Emoji | Description |
|---|---|
| 🎨 | 코드 포맷/구조 개선 |
| 📰 | 새로운 파일 생성 |
| 📝 | 사소한 코드/언어 변경 |
| 🐎 | 성능 개선 |
| 📚 | 문서 작성/수정 |
| 🐛 | 버그 리포트 ( @FIXME 태그 사용 ) |
| 🚑 | 버그 수정 |
| 🐧 | Linux 관련 수정 |
| 🍎 | Mac OS 관련 수정 |
| 🏁 | Windows 관련 수정 |
| 🔥 | 코드/파일 삭제 ( @CHANGED 태그 사용 ) |
| 🚜 | 파일 구조 변경 ( 🎨 와 함께 사용 가능 ) |
| 🔨 | 리팩토링 |
| ☔️ | 테스트 추가 |
| 🔬 | 코드 범위(scope) 추가 |
| 💚 | CI 빌드 수정 |
| 🔒 | 보안 관련 수정 |
| ⬆️ | 의존성 업그레이드 |
| ⬇️ | 의존성 다운그레이드 |
| ⏩ | 이전 버전/브랜치 기능 가져오기 |
| ⏪ | 최신 버전 기능을 이전 버전으로 백포팅 |
| 👕 | linter / strict / 경고 제거 |
| 💄 | UI / 스타일 개선 |
| ♿️ | 접근성 개선 |
| 🚧 | WIP (작업 중, @REVIEW 태그 사용) |
| 💎 | 새로운 릴리즈 |
| 🔖 | 버전 태그 |
| 🎉 | Initial Commit |
| 🔈 | 로깅 추가 |
| 🔇 | 로깅 제거 |
| ✨ | 새로운 기능 추가 |
| ⚡️ | 호환되지 않는 기능 추가 (@CHANGED 사용) |
| 💡 | 새로운 아이디어 (@IDEA 태그 사용) |
| 🚀 | 배포 / 개발 작업 관련 |
| 🐘 | PostgreSQL 관련 작업 |
| 🐬 | MySQL 관련 작업 |
| 🍃 | MongoDB 관련 작업 |
| 🏦 | 일반 DB 작업 |
| 🐳 | Docker 설정 |
| 🤝 | 파일 병합(Merge) 관련 |
3개의 댓글
중대한 변경 사항이 있다면 물론 소통을 거치긴 하겠지만, 저렇게 BREAKING CHANGE를 명시해 눈에 확 들어오게 하는 것도 꽤 괜찮네요 ?? 다른 사소한 오류들과 동일시하게 fix로 처리하게 되면 자연스레 묻히기도 할텐데, 아무래도 중요 사항인 만큼 강조시키는 무언가가 필요하긴 할 거 같았는데 역시 그런 약속이 있긴 했었군요 ...
커밋 컨벤션은 사람마다 사용하는게 달라고 초반에 정확히 잡고 가는게 중요한 것 같아요. 그리고 프로젝트 진행하다보면 feat와 fix 외에 다른 것을 사용하지 않는 것 같은데, 해당 글 참고해서 다음 프로젝트 때는 최대한 다양하게 사용해보고 싶네요.
좋은 내용 잘 보고 갑니다! 커밋 메시지에 이모지를 쓰는 경우도 있다는 건 몰랐는데 덕분에 알아갑니다.