Git

보기 좋은 깃 로그를 위한 커밋 메시지 규칙

commit, git

개발자라면 누구나 Git을 사용합니다. 개발자를 지망하는 분들에게도 실력을 떠나 자신의 개발 자취를 남기는 데에는 깃 만한 것이 없죠. 깃을 쓰게 되면 기본적으로 커밋부터 시작하게 됩니다. 커밋과 함께 필수적으로 따라오는 요소가 바로 커밋 메시지입니다. 커밋 메시지는 모든 내용이 깃 로그에 남기 때문에 잘 쓰이는 것이 중요합니다.

그 이유를 들어보면 다음과 같습니다.

  • 이해하기 쉬운 커밋 로그 가독성
  • 더 나은 협업과 리뷰 프로세스
  • 쉬운 코드 유지보수

그래서 좋은 커밋 메시지란 무엇인지 아래 참고를 바탕으로 작성해 보았습니다.

참고

Message Structure

기본적으로 제목(subject), 본문(body), 꼬리말(footer)로 구성되며, 메세지의 type으로 어떤 커밋인지 쉽게 구별합니다.

type: subject

body

footer

Type (커밋 타입)

  • feat: a new feature - 새로운 피쳐 추가
  • fix: a bug fix - 버그 해결
  • docs: changes to documentation - 프로젝트 관련 문서 수정
  • style: formatting, missing semi colons, etc; no code change - 코드 포맷 변경, 세미 콜론 누락, 코드 수정이 없는 경우
  • refactor: refactoring production code - 프로덕션 코드 리팩토링
  • test: adding tests, refactoring test; no production code change - 테스트 추가, 리팩토링 (프로덕션 코드 변경 없음)
  • chore: updating build tasks, package manager configs, etc; no production code change - 빌드 테스크 업데이트, 패키지 매니저 설정 (프로덕션 코드 변경 없음)

Subject (제목)

  • 제목과 본문을 한 줄을 띄워 분리
  • 영문 기준 50자를 넘기지 말 것
  • 첫 글자는 대문자로 시작
  • 끝에 . (마침표) 금지
  • 명령조로 작성

Body (본문)

  • 선택 사항이므로 모든 커밋에 꼭 작성할 필요는 없음
  • 어떻게 보다 무엇을, 왜 에 초점을 맞춰 작성할 것
  • 영문 기준 72자마다 줄 바꿈

Footer (꼬리말)

  • 선택 사항
  • Issue tracking ID 를 작성할 때 사용
Resolves: #123
See also: #456, #789

Message Example

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 consequenses 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
Share