Git
[Git] 좋은 commit message 작성법
itaeiou
2022. 2. 24. 15:53
반응형
좋은 Git Commit Message 작성 가이드라인
Commit Message
평소 커밋 메세지 자세하게 잘 쓰고 있다고 생각했는데, 더 깔끔한 가이드라인이 있어 공유하고자 가져왔습니다.
기존 커밋은 "[카테고리] 개발내용" 으로만 작성을 했습니다. 개인 기록용이라면 이정도로도 충분하지만, 여러 사람이 협업을 하게되면 보다 명확한 가이드라인이 필요합니다.
위 사진은 Alibaba Fusion의 Next 레포지토리와 NHN의 tui.calendar 레포지토리에서 가져온 커밋 히스토리입니다.
두 커밋 히스토리가 유사한 형태를 띄고 있는 것을 보실 수 있습니다.
가장 많이들 사용하는 좋은 커밋 메세지를 작성하기 위한 방법을 알아보겠습니다.
Commit Message 구조
type(타입) : title(제목)
body(본문, 생략 가능)
Resolves : #issueNo, ...(해결한 이슈 , 생략 가능)
See also : #issueNo, ...(참고 이슈, 생략 가능)
기본 규칙
- 제목과 본문을 빈 행으로 구분
- 제목은 영문 기준 50글자 이하
- 첫 글자는 대문자로 작성
- 제목 끝에 마침표X
- 제목은 명령문으로 사용, 과거형X
- 본문의 각 행은 영문 기준 72글자 이하
- 어떻게 보다는 무엇과 왜
Type
Type 키워드 | 사용 시점 |
feat | 새로운 기능 추가 |
fix | 버그 수정 |
docs | 문서 수정 |
style | 코드 스타일 변경 (코드 포매팅, 세미콜론 누락 등) 기능 수정이 없는 경우 |
design | 사용자 UI 디자인 변경 (CSS 등) |
test | 테스트 코드, 리팩토링 테스트 코드 추가 |
refactor | 코드 리팩토링 |
build | 빌드 파일 수정 |
ci | CI 설정 파일 수정 |
perf | 성능 개선 |
chore | 빌드 업무 수정, 패키지 매니저 수정 (gitignore 수정 등) |
rename | 파일 혹은 폴더명을 수정만 한 경우 |
remove | 파일을 삭제만 한 경우 |
대부분 가장 많이 사용하는 것은 feat와 fix입니다. style, design처럼 로직적인 변화가 없을 경우에 커밋 메세지에 명시해주는 것만으로도 추후 오류를 찾을 때 많은 도움이 됩니다.
타입 뒤에 변경된 함수나 메소드를 직접적으로 명시하기도 합니다.
ex) fix(tab): ...
관련 이슈
사용 시점 | 사용 키워드 |
해결 | Closes(종료), Fixes(수정), Resolves(해결) |
참고 | Ref(참고), Related to(관련), See also(참고) |
관련 이슈 언급은 선택사항입니다.
사용 키워드는 위와같이 다양하며, 팀에서 지정한 키워드를 사용합니다.
참고
[Git] 깃 커밋 메시지 작성법(git commit message)
반응형