업무, 개인 프로젝트 등 우리는 커밋 메시지를 매일 작성합니다.
개인적으로 그만큼 제대로 신경쓰지 않고, 커밋 메시지를 작성했던 것 같습니다.
오늘은 이렇게 신경쓰지 않은 커밋 메시지 작성법에 대해서 나눠보려고 합니다.
사실 회사에서는 이렇게 커밋 메시지를 작성하세요! 라고 하는 내용은 없습니다.
기본적으로 많이 사용하는 [FEAT]
, [FIX]
, [REMOVE]
와 같은 타입과 제목 정도는 작성하고 있었습니다.
하지만 점점 작성하다보니, 내가 커밋 메시지를 잘 쓰고 있는건가? 🤔 라는 의문이 들기 시작했습니다.
과거의 커밋 이력을 보고 있는데, 제가 작성한 커밋 메시지를 이해 못하고 있었습니다... 🤯
이 순간은 매우매우 충격적이었습니다..
사실 평소에도 나는 커밋 메시지를 자세하게 잘 쓰고 있어! 라는 생각을 하지는 않았습니다.
하지만 실제로 커밋 메시지를 보니 왜 이런 기능을 작성했는지, 자세한 내용은 하나도 이해가 되지 않았습니다..
대충 어떤 내용의 작업이라는 것만 적혀있고, 왜 이러한 코드를 썼는지, 자세한 내용들이 안 남아 있었습니다.
부족함을 알았으니, 미래의 나를 조금이라도 덜 힘들게 하기 위해서, 커밋 메시지 작성법에 대해서 정리를 해보려고 합니다.
제목, 본문, 꼬리말, 세가지 파트로 구분합니다.
각 파트는 빈 줄을 두고 구분합니다.
다른 포스팅을 많이 참고하려고 했는데, 대부분 동일한 컨벤션을 가지고 있었습니다.
type: 제목
본문
꼬리말
type: 제목
type:
feat
: 새로운 기능 추가fix
: 버그 수정docs
: 문서 업데이트style
: style
과 관련 코드 수정refactor
: 코드 리팩토링test
: 테스트 코드 작성, 수정chore
: 패키지 설치 및 환경 설정rename
: 파일 혹은 폴더명 수정 혹은 이동 remove
: 파일 삭제제목
feat: 네이버 소셜 로그인 기능을 구현 함. (X)
feat: 네이버 소셜 로그인 기능 구현 (O)
다른 포스팅을 많이 참고하려고 했는데, 대부분 비슷한 컨벤션을 가져가고 있었습니다.
그리고 type:
을 7가지로 작성하신 분들이 많았습니다.
개인적으로 굳이 7개로 한정해서 나눌 필요는 없다고 생각이 듭니다.
type
은 자유롭게 넣고 빼고 해도 괜찮다고 생각합니다.
(사실 feat
, fix
를 제일 많이 사용하겠지요..!)
대문자로 시작하지 않는다는 규칙도 있었는데요.
이 부분은 영어로 커밋 메시지를 작성할 때 대문자로 시작하지 말라는 이야기였습니다.
개인적으로 아직은 영어로 커밋 메시지를 작성할 용기가 나지 않기 때문에.. 패스하도록 하겠습니다 🏃
side effect
나 고려해야 될 사항이 있다면 작성합니다.예시를 한 번 작성해보려고 했는데요.
무엇을, 왜 변경했는지에 대한 내용을 작성하는게 꽤나 힘든 것 같습니다. 🤔
optional
입니다.유형: #이슈 ID
형식으로 작성합니다.Fixes: #45
Related to: #34, #23
대부분의 개발자들은 커밋의 순서를 따라가면서 다른 동료분들이 작성한 코드를 파악합니다.
그리고 코드에 대한 의견이 있다면, 리뷰를 남기면서 코드리뷰를 진행하기도 합니다.
저 또한 코드리뷰를 진행할 때 그런식으로 진행하는데요.
이 때 커밋 메시지를 잘 작성해두면 코드 리뷰 혹은 저처럼 과거의 내용을 파악할 때 조금 더 효과적으로 내용을 확인할 수 있을거라고 기대합니다.