좋은 커밋 메세지 작성하는 방법
프로젝트 협업을 할 때 커밋 메시지 작성은 매우 중요합니다. 이전에 다녔던 회사에서 커밋 메시지에 대한 규칙이 따로 없었기에 이번 기회에 커밋 메시지 작성하는 방법에 대해 알아보기로 했습니다. 협업을 하거나 혹은 개인 프로젝트를 진행할 때 미리 좋은 커밋 메시지 습관을 들여놓는 차원에서 좋은 커밋 메시지 규칙들을 정리해봤습니다.
○ Commit 메시지 구조
type(타입) : title(제목)
body(본문, 생략 가능)
Resolves : #issue, ... (해결한 이슈, 생략 가능)
See also : #issue, ... (참고 이슈, 생략 가능)
○ Commit 메시지 규칙
1. Commit 타입 지정
| Type 키워드 | 사용 시점 |
| feat | 새로운 기능 추가 |
| fix | 버그 수정 |
| docs | 문서 수정 |
| style | 코드 스타일 변경 (코드 포매팅, 세미콜론 누락 등) 기능 수정이 없는 경우 |
| design | 사용자 UI 디자인 변경 (CSS 등) |
| test | 테스트 코드, 리팩토링 테스트 코드 추가 |
| refactor | 코드 리팩토링 |
| build | 빌드 파일 수정 |
| ci | CI 설정 파일 수정 |
| perf | 성능 개선 |
| chore | 빌드 업무 수정, 패키지 매니저 수정 (gitignore 수정 등) |
| rename | 파일 혹은 폴더명을 수정만 한 경우 |
| remove | 파일을 삭제만 한 경우 |
대부분 많이 사용하는 것 : feat, fix
style, design처럼 로직의 변화가 없을시 커밋 메시지에 명시해주기만 해도 충분합니다.
타입 뒤에 변경된 함수나 메소드를 직접적으로 명시하는 경우도 있습니다.
ex) fix(tmethod): ...
2. 제목과 본문은 빈 행으로 분리
3. 제목 행은 50자로 제한
4. 제목 행의 첫 글자는 대문자로 시작 (영문)
read the docs (x)
Read the docs (o)
5. 제목 행 끝에 마침표 X
Read the docs. (x)
Read the docs
6. 제목은 명령형으로 작성
Docs are ready x
Read the docs
7. 본문에는 추가 or 변경 내용과 이유를 적는다
- 무엇을 추가 또는 변경했는지와 그 이유를 적는다
- '어떻게(how)'는 되도록 지양한다
*정리 후 느낀 점
주변 개발자들이 커밋메시지를 어떻게 적나 구글에서 찾아본 결과 영어로 적는 사람도 있었고 한국어로 적는 사람도 있었다. 하지만 가장 많이 쓰는 방식은 prefix를 영어로 적고 그 뒤에 한글로 쓰는 방식이었다.
만약에 영어를 주 언어로 사용하는 개발자와 협업해야 한다면 영어로 적겠지만, 그게 아니라면 한국어로 적어도 괜찮다고 생각한다.
*참고 :
https://richone.tistory.com/26
'Git' 카테고리의 다른 글
| Git Bash에서 add, commit, push 기능 활용해보기 (0) | 2022.12.07 |
|---|