Git Commit Convention

형상관리 툴 Git을 사용하며 Commit 시 Commit Message를 작성하는 규칙을 Commit Convention이라고 한다.

 

협업 시 특정 Commit의 내용을 통일된 형태로 기록하기 위해 혹은 시간이 지나도 특정 Commit을 보다 용이하게 검색하기 위해

 

Commit Convention을 준수하여 Commit Message를 작성하는 것이 중요하다.

 

이 글에서는 Udacity Style을 기본으로 한다.

 

구조

 

먼저 Commit Message는 크게 다음의 구조를 가진다.

type: Subject

body

footer

 

순서대로 제목, 본문, 바닥글로, 본문과 바닥글은 필수는 아니고 선택 사항이다.

 

제목

 

제목은 type과 subject로 구성된다.

 

type

• feat: 새로운 기능 추가
• fix: 버그 수정
• docs: 문서 수정
• style: 코드 포맷팅
• refactor: 리팩토링
• test: 테스트 코드, 리팩토링 테스트 코드 추가
• chore: 빌드 작업 수정, 패키지 매니저 수정*
• comment: 주석 추가 및 수정
• remove: 파일 및 폴더 삭제
• rename: 파일 및 폴더 이름 수정

* chore는 코드의 동작에 직접적인 영향을 주지는 않지만 프로젝트 관리와 작업 환경을 개선하는 데 필요한 일들을 포함한다.

 

subject

• 50자 이내여야 한다.
• 마침표 및 특수기호는 사용하지 않는다.
• 대문자로 시작하는 동사원형으로 시작한다.
  •  Add: 추가
  • Remove: 삭제
  • Simplify: 단순화
  • Update: 보완
  • Implement: 구현
  • Prevent: 방지
  • Move: 이동
  • Rename: 이름 변경

본문

 

선택 사항으로, Commit의 what과 why를 작성한다.

 

바닥글

 

선택 사항으로, 이슈 트래커 ID를 작성한다.

 

유형: #이슈 번호 형식으로 작성하며 이슈 번호가 여러 개일 땐 쉼표로 구분한다.

 

유형으로는 다음이 있다.

• Fixes: 이슈 수정 중
• Resolves: 이슈 해결
• Ref: 참고할 이슈
• Related to: Commit과 관련된 이슈

 

예시

 

위 내용을 토대로 아래와 같은 Commit Message를 작성할 수 있다.

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