Git 커밋 메시지 작성법

🌊·2023년 5월 1일
0
post-thumbnail

개요

업무, 개인 프로젝트 등 우리는 커밋 메시지를 매일 작성합니다.

개인적으로 그만큼 제대로 신경쓰지 않고, 커밋 메시지를 작성했던 것 같습니다.
오늘은 이렇게 신경쓰지 않은 커밋 메시지 작성법에 대해서 나눠보려고 합니다.
사실 회사에서는 이렇게 커밋 메시지를 작성하세요! 라고 하는 내용은 없습니다.

기본적으로 많이 사용하는 [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

마무리

대부분의 개발자들은 커밋의 순서를 따라가면서 다른 동료분들이 작성한 코드를 파악합니다.
그리고 코드에 대한 의견이 있다면, 리뷰를 남기면서 코드리뷰를 진행하기도 합니다.

저 또한 코드리뷰를 진행할 때 그런식으로 진행하는데요.
이 때 커밋 메시지를 잘 작성해두면 코드 리뷰 혹은 저처럼 과거의 내용을 파악할 때 조금 더 효과적으로 내용을 확인할 수 있을거라고 기대합니다.

출처

0개의 댓글