Git - Commit Message Conventions

Git Commit Message Conventions

지금까지 Git을 사용할 때 Commit Message Conventions에 대한 정보를 전혀 알지 못 하고 있었다.
짧았지만 우테코 프리코스를 진행하며 Java Code Convetions와 Git Commit Message Conventions에 대한 정보를 알게 되었다.
그동안 지키지 못 한 Code Conventions와 Commit Message Conventions을 작성한 내가 창피해진다.

그래서!!! Commit Message Conventions에 대한 내용을 포스팅하고 싶어졌다.

커밋 메시지 구조

기본적인 커밋 메시지 구조는 아래와 같다.

제목 (Type: Subject)

본문 (Body)

꼬리말(Footer)

Type

커밋의 타입 구성은 다음과 같다.

• Feat: 새로운 기능 추가
• Fix: 버그 수정
• Design: CSS등 사용자 UI 디자인 수정
• !BREAKING CHANGE: 대규모 API 수정
• !HOTFIX: 중요도가 높은 치명적인 버그를 고칠 때
• Style: 코드 포맷 변경, 세미 콜론 누락 등 코드 수정이 없는 경우
• Refactor: 프로덕션 코드 리팩토링
• Comment: 필요한 주석 추가 및 변경
• Docs: 문서 수정
• Test: 테스트 코드, 리팩토링 테스트 코드 추가 (실제 사용하는 코드 변경 없음)
• Chore: 빌드 업무 수정, 패키지 매니저 수정, 패키지 관리자 구성 등 업데이트 (실제 사용하는 코드는 변경 없음)
• Rename: 파일 혹은 폴더명을 수정 or 옮기는 작업인 경우
• Remove: 파일 삭제하는 작업만 수행하는 경우

추가적인 문맥 정보를 제공하기 위한 목적으로 괄호에 적을 수 있다.

Feat(CommentWrite)
Docs(Requirements)

Type Subject

• 제목은 50자 이내로 작성
• 첫글자는 대문자로
• 마침표 및 특수기호 사용하지 않는다.
• 영문으로 작성하는 경우 동사를 가장 앞에 명령어로 작성
• 과거시제는 사용하지 않는다.
• 간결하고 요점적으로(개조식 구문) 작성한다

Fixed -> Fix
Added -> Add
Modified -> Modify

Body

• 72자 이내로 작성한다.
• 최대한 상세하게 작성한다. (코드 변경의 이유를 명확하게 작성하자.)
• 왜? 무엇을? 변경했는지 작성하자.

Footer

• 선택사항으로 작성하자
• issue tracker ID를 명시하고 싶은 경우 작성한다.
• 유형: #이슈 번호
  • 위 형식으로 작성한다.
• 여러 개의 이슈번호는 쉼표(,)로 구분한다.
• 이슈 트래커 유형은 다음 중 하나를 사용한다.
  • Fixes: 이슈 수정중(아직 해결되지 않았을 때)
  • Resolves: 이슈를 해결했을 때 사용
  • Ref: 참고할 이슈가 있을 때 사용
  • Related to: 해당 커밋에 관련된 이슈번호(해결되지 않은 경우)

Fixes: #45 Related to: #34, #23

Example

예시 1

Feat: 회원 가입 기능 구현

SMS, 이메일 중복확인 API 개발

Resolves: #123
Ref: #456
Related to: #48, #45

예시 2

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