깃 커밋 메시지 컨벤션 (Git Commit Message Convention)

커밋 메시지 컨벤션...Why?

사실 지금껏 혼자서 프로젝트를 진행해오는 일이 많아서 깃 커밋 메시지를 나만 알아보면 되므로 중구난방으로 적는 일이 많았다.

그러던 중 최근에 팀 프로젝트를 진행하면서 남이 알아보기 쉽게끔 신경써서 커밋 메시지를 작성해야할 일이 생겼다.

그런데 팀 플젝이 아니더라도 몇 개월 뒤에 내가 쓴 커밋 메시지를 보게 되면 이 당시의 내가 무슨 생각으로 커밋 메시지를 작성했는지 알 수가 없다....(나를 위해서 라도 커밋 메시지를 신경써서 적도록 하자.)

정리하자면, 크게 3가지 이유로 좋은 커밋 메시지를 작성해야 할 것이다.

1. 더 좋은 커밋 로그 가독성
2. 더 나은 협업과 리뷰 프로세스
3. 더 쉬운 코드 유지 보수

---

커밋 메시지 구조 (Commit Message Structure)

커밋 메시지 구조는 제목(subject) / 본문(body) / 꼬리말(footer)로 구성된다.

본문과 꼬리말은 반드시 포함될 필요는 없다.

type : subject (이 곳은 제목이 들어갈 자리입니다.)

body (이 곳은 본문 내용이 들어갈 자리입니다.)

footer (이 곳은 꼬리말이 들어갈 자리입니다.)

 

커밋 타입 (Commit Type)

• feat : 새로운 기능 추가
• fix : 버그 수정
• docs : 문서 수정
• style : 코드 포맷팅, 세미콜론 누락, 코드 변경이 없는 경우
• refactor : 코드 리팩토링
• test : 테스트 코드, 리팩토링 테스트 코드 추가
• chore : 빌드 업무 수정, 패키지 매니저 수정

 

제목 (Subject)

• 커밋 메시지 제목은 제일 앞에 제목의 타입을 붙여준다. 커밋 타입의 종류는 위 내용을 참고한다.
• 제목은 50자를 넘기지 않고, 대문자로 작성하고 마침표를 붙이지 않는다.
• 과거 시제를 사용하지 않고 명령어로 작성한다.
• 커밋 유형들이 복합적인 경우에는 최대한 분리하여 커밋한다.

 

본문 (Body)

• 선택 사항이므로 작성하지 않아도 무방하다.
• 부연설명이 필요하거나 커밋의 이유를 전달해야할 경우 작성한다.
• 내용은 어떻게 변경하였는지 보다 무엇을, 왜 변경하였는지를 설명하는 위주로 작성한다.
• 한 줄이 72자를 넘기지 안고 제목과 구분되게 한 줄을 띄우고 작성한다.

 

푸터 (Footer)

• 선택 사항이기 때문에 작성하지 않아도 무방하다
• 보통 이슈를 추적하기 위해 이슈 트래커 ID를 넣어주는 용도로 사용된다.

 

예시!! (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

내가 직접 써본 예시

feat : 사용자 정보 수정 구현

패스워드 변경 뿐만 아니라 사용자의 별명이나 연락처를 변경할 수 있도록 새로운 기능 추가

관련 이슈 트래커 ID
Resolves: #123
See also: #456, #789

---

참조

Git - 커밋 메시지 컨벤션

 

 

깃 커밋 메시지 컨벤션 (Git Commit Message Convention)

 

좋은 git 커밋 메시지를 작성하기 위한 7가지 약속 : TOAST Meetup