Git

Git Commit Message Convention

크레리누 2021. 9. 14. 16:45

git commit 컨벤션이란?

요즘 프로젝트를 하면서 git을 많이 사용하고있다. 그중에서도 commit은 필수로 해야되는 일 중 하나인데, commit 메세지를 너무 두서없이 대충쓰는것 같아서 찾아봤더니 커밋 메세지 습관을 규격화한 git 커밋컨벤션이 있기에 내용을 포스팅한다.

들어가며

왜 커밋메세지 스타일을 통일화하는게 좋은가? 바로 프로젝트는 보통 협업하면서 하기때문에 여러 사람들이 보기때문이다. 이글은 Udacity Git Commit Message Style Guide을 참고했다.

commit message

Message Structure (메세지 구조)

type: Subject 

body 

footer

  • type : commit type 명시

  • subject : 최대 50글자가 넘지 않도록 하고 마침표는 찍지 않는다. 영문으로 표기하는 경우 동사(원형)를 가장 앞에 두고 첫 글자는 대문자로 표기

  • body : 긴 설명이 필요한 경우에 작성한다. 무엇을, 왜 했는지를 작성하며 최대 75자를 넘기지 않도록 한다.

  • footer : issue tracker ID를 명시하고 싶은 경우에 작성.

    Type

타입은 태그와 제목으로 구성되고, 태그는 영어로 쓰되 첫 문자는 대문자로 한다.

tag 설명
feat 새로운 기능을 추가할 경우
fix 버그를 고친 경우
docs 문서를 수정한 경우
style 코드 포맷 변경, 세미 콜론 누락, 코드 수정이 없는 경우
refactor 프로덕션 코드 리팩토링
test 테스트 추가, 테스트 리팩토링(프로덕션 코드 변경 X)
chore 빌드 태스트 업데이트, 패키지 매니저를 설정하는 경우(프로덕션 코드 변경 X)

예시

제목만 적을경우

Feat: upodate login API 함수

전부 적을 경우

feat: Summarize changes in around 50 characters or less 
More detailed explanatory text, if necessary. Wrap it to about 72 characters or so. In some contexts, the first line is treated as the subject of the commit and the rest of the text as the body. The blank line separating the summary from the body is critical (unless you omit the body entirely); various tools like `log`, `shortlog` and `rebase` can get confused if you run the two together. 

Explain the problem that this commit is solving. Focus on why you are making this change as opposed to how (the code explains that). Are there side effects or other unintuitive consequences of this change? Here's the place to explain them. 

Further paragraphs come after blank lines. 

- Bullet points are okay, too 

If you use an issue tracker, put references to them at the bottom, like this: 

Resolves: #123 
See also: #456, #789
저작자표시 (새창열림)