들어가며..
git 커밋 메시지를 일관성 있게 잘 작성해야 하는 이유는 다음과 같다.
- 더 좋은 커밋 로그 가독성
- 더 나은 협업과 리뷰 프로세스, 팀원들과의 원활한 커뮤니케이션
- 더 쉬운 코드 유지보수
커밋 메시지 컨벤션이 없는 경우, 일관성이 없는 메시지 내용은 각 커밋 위치에서 어떤 작업을 했는지 명확하게 알아보기 어렵거나 시각적 통일성을 떨어뜨려 커밋 히스토리 파악에 어려움이 있을 수 있다.
혼자가 아닌 여럿이서 같이 일하는 실무에서 커밋 메시지를 규칙으로 작성하는 것은 중요하다.
보편적으로 사용되는 좋은 커밋 메시지 작성 기준에 대해 알아보자 !
좋은 git 커밋 메시지를 작성하기 위한 7가지 규칙
아래 규칙은 커밋 메시지를 영어로 작성하는 경우에 최적화되어 있다.
한글 커밋 메시지 작성 시 회사나 팀 내에서 정한 정책에 따라 유연하게 작성하면 될 것 같다.
- 제목과 본문 한 줄 띄워서 분리하기
- 제목은 영문 기준 50자 이내로 제한하기
- 제목은 명령문으로 하고, 과거형 사용하지 않기
- 제목 첫 글자를 대문자로 작성하기
- 제목 끝에 마침표(.) 넣지 않기
- 본문은 영문 기준 72자마다 줄 바꾸기
- 본문은 어떻게 보다는 무엇을, 왜에 맞춰서 작성하기
Commit 메시지 작성법
Commit 메시지 구조는 아래와 같이 제목/본문/꼬리말로 구성한다.
[Type]: [Subject]
[Body]
[Footer]
Type은 해당 commit의 성격을 나타낸다.
- feat - 새로운 기능 추가
- fix - 버그 수정
- refactor - 코드 리팩토링
- test - 테스트 코드 추가, 수정, 삭제
- build - 빌드 관련 파일 수정
- docs - 문서 관련 추가, 수정, 삭제
- style - 코드 스타일 혹은 포맷과 같이 비즈니스 로직 변경이 없는 경우
Type을 이모지로 하는 방법도 있다. (gitmoji.dev/)
Body는 본문으로, 헤더에서 생략한 상세 내용을 작성하면 된다. 헤더로 충분한 표현이 가능하다면 생략할 수 있다.
Footer는 어떤 이슈에서 왔는지와 같은 참조 정보를 추가하는 용도로 사용된다. (issue tracker id 작성할 때 사용) 이슈 해결 시 사용되는 해결, 해당 커밋에 관련된 이슈 번호를 넣는 관련, 참고할 이슈가 있는 경우에 사용하는 참고 타입을 넣어 사용할 수 있다. 선택사항으로, 모든 커밋에 꼬리말을 작성할 필요는 없다.
🚩 Commit Message 예시)
feat: Gmail 로그인 기능 추가
Firebase Authentication 이용하여 Gmail 로그인 연동 기능을 추가함
해결: close #123
참고
https://meetup.toast.com/posts/106
https://junhyunny.github.io/information/github/git-commit-message-rule/
'Devlog > Git' 카테고리의 다른 글
[Git] 상황별 Git과 충돌(Conflict) 다루기 (0) | 2022.07.05 |
---|---|
[Git] Git 개념과 기본적인 명령어 (0) | 2022.07.05 |