TIL 230228 좋은 git commit 메세지 적기

commit 메세지를 잘 적으면 나중에 변경 사항을 살펴보기 쉽다. commit 메세지를 효율적이고 통일되게 적고 싶어서 한 번 정리를 하려고 했는데 드디어 하게 되었다! 😀 여기에 깃모지를 붙여서 사용해야지!

 

commit 메시지를 적을 때 지키면 좋은 점

대문자와 구두점

첫 번째 단어는 대문자로 쓰고 마지막에 구두점을 쓰지 않는다. 일반 커밋(git commit -m <내용>)을 사용하는 경우 모두 소문자로 작성해야한다.

 

줄 바꿈

제목과 내용 사이에 공백을 두는 것이 좋다.

내용의 문단이 달라질 때는 문단 사이에 공백을 두는 것이 좋다.

 

분위기

제목 줄에서 명령적인 분위기를 사용한다. ( 예 : Add fix for dark mode toggle state )

commit 타입

commit 타입을 지정한다. 변경 사항을 설명하기 위해 일관된 단어 집합을 사용하는 것이 권장된다.

( 예: Bugfix, Update, Refactor, Bump 등 )

길이

제목은 50자를 초과하지 않아야 하며 본문은 72자로 제한되어야 한다. 제목은 50자를 넘어가면 github에서 줄바꿈표가 생긴다.

내용

아마도, 내 생각에는, ~것 같다 등의 어휘를 사용하지 않는다. 변경할 것이 아닌 변경된 것에 대해 적는다.

필요하다면 -이나 들여쓰기를 사용할 수 있다.

무엇을 왜 변경했는지를 적으면 좋다.

• Why have I made these changes? - 왜 변경했는가 ?
• What effect have my changes made? - 변경 후 어떻게 변화했는가 ?
• Why was the change needed? - 변경이 왜 필요했는가 ?
• What are the changes in reference to? - 무엇과 관련하여 변경했는가 ?

오타

오타가 없는지 꼼꼼하게 확인한다.

 

 

commit 타입 분류

commit 타입 분류는 간결한 설명을 위해 모두 소문자여야 한다.

• feat – a new feature is introduced with the changes ( 새로운 기능이 도입되었을 때 )
• fix – a bug fix has occurred ( 버그를 고쳤을 때 )
• chore – changes that do not relate to a fix or feature and don't modify src or test files (for example updating dependencies) ( src나 테스트 파일의 수정이 없고 수정이나 기능에 관계없이 변경사항이 있을 때, 예 : 디펜던시가 업데이트 되었을 때)
• refactor – refactored code that neither fixes a bug nor adds a feature ( 버그를 고치거나 새로운 기능을 추가한게 아닌 코드를 리팩토링 했을 때 )
• docs – updates to documentation such as a the README or other markdown files ( 리드미와 같은 문서를 업데이트 했을 때 )
• style – changes that do not affect the meaning of the code, likely related to code formatting such as white-space, missing semi-colons, and so on. ( 로직에는 변화가 없고 공백이나 세미콜론 같은 코드 형식에 변화가 있을 때 )
  + 또는 CSS 스타일의 변화가 생겼을 때 사용해도 되는 것 같다.
• test – including new or correcting previous tests ( 새로운 테스트를 짜거나 기존 테스트를 고쳤을 때 )
• perf – performance improvements ( 성능이 향상 됐을 때 )
• ci – continuous integration related ( CI와 연관이 있을 때 )
• build – changes that affect the build system or external dependencies ( 빌드 시스템이나 외부 디펜던시가 바뀌었을 때 )
• revert – reverts a previous commit ( 이전 커밋으로 되돌릴 때 )

 

conventional commit 예시

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

fix: fix foo to enable bar -> 소문자

This fixes the broken behavior of the component by doing xyz. 

BREAKING CHANGE -> 큰 변화에 대해 설명할 수 있다.
Before this fix foo wasn't enabled at all, behavior changes from <old> to <new>

Closes D2IQ-12345 -> 푸터를 선택적으로 사용할 수 있다.

commit 컨벤션 가이드라인은 README 파일에 적어두는 것이 좋다.

 

좋은 commit log와 나쁜 commit log 비교

--Good--
feat: improve performance with lazy load implementation for images
chore: update npm dependency to latest version
Fix bug preventing users from submitting the subscribe form
Update incorrect client phone number within footer body per client request

--Bad--
fixed bug on landing page
Changed style
oops
I think I fixed it this time?
empty commit messages

---

그동안 commit 컨벤션을 지켜 적고 있었는데 보편적인 방식에서 틀린 부분이 있었던 걸 알게 됐다. 이제부터는 commit 타입도 소문자로 적고 제목과 본문을 한 줄 띄워줘야겠다. 본문도 왜 바꿨는지를 넣어서 구체적으로 적어야겠다. 타입도 더 명확하게 사용할 수 있을 것 같다.

 

참고 링크 1

참고 링크 2