[Commit Message Convention]
다른 사람과 협업할 때 어떻게 하면 더 잘할 수 있을까?
잘 만든 커밋 메시지는 다른 개발자에게 변경 사항을 전달하는 가장 쉽고 간편한 방법이다. 그래서 기업의 대규모 프로젝트는 당연하고 협력의 비중이 낮은 소규모의 프로젝트에서도 커밋 컨벤션을 따로 만들어서 규칙을 지키기도 한다.
좋은 커밋을 사용하기 위한 커밋 컨벤션을 정리해보자
🔗 커밋 메시지 구조
커밋 메시지에 대한 약속
커밋 메시지 구조는 크게 3가지로 나뉜다.(제목, 본문, 꼬리말)
type: Subject -> 제목
(한줄 띄어 분리)
body(생략 가능) -> 본문
(한줄 띄어 분리)
footer(생략 가능) -> 꼬리말✏️ Commit type
| Tag Name | Description |
|---|---|
| Feat | 새로운 내용 추가 |
| Fix | 버그 수정 또는 typo |
| Refactor | 리팩토링 |
| Design | CSS 등 사용자 UI 디자인 변경 |
| Comment | 필요한 주석 추가 및 변경 |
| Style | 코드 포맷팅, 세미콜론 누락, 코드 변경이 없는 경우 |
| Test | 테스트(테스트 코드 추가, 수정, 삭제, 비즈니스 로직에 변경이 없는 경우) |
| Chore | 위에 걸리지 않는 기타 변경사항(빌드 스크립트 수정, assets images, 패키지 매니저 등) |
| init | 프로젝트 초기 생성 |
| Rename | 파일 혹은 폴더명 수정하거나 옮기는 경우 |
| Remove | 파일을 삭제하는 작업만 수행하는 경우 |
| Docs | 문서 수정 |
개인적인 추가 설명
코드 포맷팅:코드를 일관된 스타일과 구조로 정리하는 작업(들여쓰기,줄 바꿈, 공백, 주석)으로 가독성이 향상될 수 있다.
리팩토링: '결과의 변경 없이 코드의 구조를 재조정함' 주로 가독성을 높이고 유지보수를 편하게 한다.
Docs: README.md, 페이지 목록 HTML 작성 등
Chore: 작업환경 관련 소스(Gulp, lint, settings 등)
나의 사용 예시
$ git commit -m "fix: 컴포넌트 수정"[출처]
https://kdjun97.github.io/git-github/commit-convention/
https://velog.io/@archivvonjang/Git-Commit-Message-Convention
🚀 DevLog