[Git] Commit message 규칙

 

 

개인 프로젝트 마이그레이션 과정 중 중구난방인 커밋메시지로 히스토리 확인이 어렵다.. 

그래서 찾아본 커밋 메시지 작성 규칙

 

목적

커밋 메시지 스타일을 구조화해 일관성 있게 사용하는 이유!

• 코드 리뷰 시간을 단축하고 능률적으로 처리하기 위해서
• 변경 사항을 이해해는데 도움을 주기 위해서
• 코드만으론 설명이 어려운 "왜 이렇게 했을까"를 설명하기 위해서
• 추후 작업할 사람이 왜/어떻게 변경 사항이 만들어졌는지 이해하는데 도움을 주고 문제 해결과 디버깅을 쉽게 만들기 위해서

 

 

Commit message 규칙

① 제목과 본문을 빈 행으로 구분

② 제목을 50글자 내로 제한

③ 제목 첫 글자는 대문자로 작성

④ 제목 끝에 마침표 넣지 않기

⑤ 제목은 명령문으로 사용하며 과거형을 사용하지 않는다

⑥ 본문의 각 행은 72글자 내로 제한

⑦ 어떻게 보다는 무엇과 왜를 설명

 

 

 

커밋 메시지 구조

제목, 본문, 꼬리말 3가지로 빈 줄로 구분

본문과 꼬리말은 선택사항

type : subject

body

footer

 

 

 

커밋 메시지 예시

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

 - Typically a hyphen or asterisk is used for the bullet, preceded
   by a single space, with blank lines in between, but conventions
   vary here

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

Resolves: #123
See also: #456, #789

 

 

① 제목 subject

type: [#issueNumber ] subject

• 해당 커밋의 유형 type과 제목은 필수 사항
  • 타입은 소문자로 작성
• [] 내용은 옵션, 이슈 트래킹에서 제공하는 이슈 번호를 넣어준다
  • 여러 개의 이슈가 합쳐진 경우에는 생략하는 것이 좋다
• 제목은 해당 커밋의 주요 내용을 간략하게 작성
  
  • 제목은 최대 50자를 넘지 않도록
  • 명령조로 작성은 동사 원형으로 작성을 의미 
    • 회원 서비스 추가 

 

 

①  종류 type

• 상황에 맞춰 적절히 사용

fix	기능 버그 픽스
docs	문서(주석) 추가/수정
style	스타일 관련 작업을 했을 경우, 서식 지정, 세미콜론 누락 등 코드 직접적인 변경 없음
refactor	코드 리팩토링했을 경우, 코드 리뷰 등으로 로직(기능)의 변화없이 단순 함수 내부에서만 사용하는 이름을 변경 등
test	테스트 코드를 별도 추가/변경했을 경우(만약 기능을 추가하면서 테스트 코드를 동시에 작성했을 경우 feat 타입 사용)
chore	기능/테스트 코드, 문서, 스타일, 리팩토일을 제외한 배포, 빌드 등과 같은 프로젝트의 기타 작업들에 대해 추가/수정했을 경우, 코드 스타일을 수정했을 때도 사용
feat	새로운 기능을 추가하거나 기존의 기능을 요구 사항 변경으로 변경한 경우, 기능 추가와 수정을 나누어서 쓰고 싶은 경우 아래 2개의 타입으로 사용
	new	새로운 기능을 추가한 경우
	improve	기존 기능을 수정한 경우, 요구 사항이 변경되어 수정된 경우
release	릴리즈 하기 위해 패키지 버전을 올리거나 릴리즈 버전 커밋을 찍기 위한 경우
ci	CI관련 설정 수정에 대한 커밋
build	빌드 관련 파일 수정에 대한 커밋

 

 

② 본문 body

• 본문은 선택 사항
• 해당 커밋에서 수정된 상세내역을 작성
• 한 줄에 72자 이하로 작성
• 어떻게 보다는 무엇을 왜에 맞춰 작성
  • 수정 내역을 * 기호 이용해 하나씩 입력하는 방법도 좋다
  • 어떻게 고쳐졌는지는 코드 히스토리 통해 파악 가능하니 무엇을 왜 했는지 작성

 

③ 꼬리말 footer

• 꼬리말은 선택사항
• 해당 커밋과 관련된 이슈 트래킹 번호 입력
  • 꼬리말에 이슈 번호를 라벨과 함께 추가

 

③ 라벨

Resolves	문의나 요청에 의한 이슈
Closes	일반적인 개발과 관련된 이슈
Fixes	버그 픽스, 핫 픽스 관련 이슈
See also	해당 커밋의 이슈와 연관되어 있는 이슈들이 존재하는 경우

 

 

참고

https://cbea.ms/git-commit/

https://blog.munilive.com/posts/my-git-commit-guide.html

https://udacity.github.io/git-styleguide/

https://blog.ull.im/engineering/2019/03/10/logs-on-git.html