Conventional Commits

종원유·2023년 7월 26일
0

Git

목록 보기
2/4
post-thumbnail

Conventional Commits

Conventional Commits 스펙은 커밋 메세지에 곁들여진 가벼운 컨벤션으로 명확한 커밋 히스토리를 생성하기 위한 간단한 규칙을 제공한다.

  • 커밋 히스토리를 이용한 자동화 도구를 만들 수 있음.
  • 커밋 메세지에 신규 기능 추가, 문제 수정, 큰 변화가 있음을 기술함으로써 Sementic Versioning의 역할을 한다.

Why Use Conventional Commits?

  • CHANGELOG를 자동으로 생성한다.
  • Simentic Versioning을 자동화 할 수 있다.
  • 팀 동료, 타인 등에게 변화의 본질을 전달할 수 있다.
  • 빌드 배포 프로세스를 수행할 수 있다.
  • 구조화 된 커밋 히스토리로 프로젝트에 기여하기 더 쉽도록한다.

구조

<타입>[적용 범위(선택 사항)]: <설명>

[본문(선택 사항)]

[꼬리말(선택 사항)]

타입

fix

코드베이스에서 버그를 패치하는 fix 타입의 커밋
Simentic Versioning에서 PATCH와 관련

feat

코드베이스에서 새 기능이 추가되는 feat 타입의 커밋
Simentic Versioning에서 MINOR와 관련

BREAKING CHANGE

BREAKING CHANGE: 라는 꼬리말을 가지거나 타입/스코프 뒤에 !문자열을 붙인 커밋은 단절적 API 변경(breaking API change)가 있음을 알린다.
어떤 커밋 타입에도 BREAKING CHANGE는 해당 커밋에 포함할 수 있다.
Simentic Versioning에서 MAJOR와 관련

커밋 메세지와 BREAKING CHANGE 꼬리말을 가지는 커밋 메세지

feat: allow provided config object to extend other configs

BREAKING CHANGE: `extends` key in config file is now used for extending other config files

BREAKING CHANGE 에 주의를 주기 위해 !를 포함한 커밋 메세지

feat!: send an email to the customer when a product is shipped

BREAKING CHANGE 꼬리말과 !를 함께 포함한 커밋 메세지

chore!: drop support for Node 6

BREAKING CHANGE: use JavaScript features not available in Node 6.

그 외

그 외에도 아래의 타입을 사용할 것을 권장

  • build: 시스템 또는 외부 종속성에 영향을 미치는 변경사항(npm, gulp, yarn)
  • chore: 코드 수정 없이 설정 변경
  • ci: ci구성파일 및 스크립트 변경
  • docs: documentation 변경
  • style: 코드 의미에 영향을 주지 않는 변경사항
  • refactor: 버그를 수정하거나 기능을 추가하지 않는 코드 변경, 리팩토링
  • perf: 성능 개선
  • test: 누락된 테스트 추가 또는 기존 테스트 수정

위 타입의 경우 컨벤션 커밋 규격에 의무화되지 않고, Simentic Versioning에 잠재적인 영향을 주지 않음(BREAKING CHANGE가 포함되지 않을 때).
추가적인 문맥 정보를 제공하기 위한 목적으로 사용되는 적용 범위는 커밋의 타입에 덧붙일 수 있다.

적용 범위를 덧붙일 땐, ()를 사용한다.

적용 범위를 가지는 커밋 메세지

# 1
feat(parser): 배열에 기능 추가

# 2
feat(lang): add polish language

본문이 없는 커밋 메세지

docs: correct spelling of CHANGELOG

규칙

  1. 모든 커밋에는 feat, fix 같은 명사로 된 접두어를 포함해야 하고 그 뒤로 선택 사항인 적용 범위, !, 그리고 필수인 :과 공백이 있어야 한다.
  2. 적용 범위는 타입 다음에 기술한다. 그리고 적용되는 영역을 기술하는 명사로 괄호에 감싸져야 한다.(ex. fix(parser))
  3. 설명은 타입/적용 범위 접두어 뒤에 있는 :과 공백 다음에 작성되어야 한다.(ex. fix(order): 버그수정)
  4. 더 긴 커밋 본문은 설명 다음에 위치할 수 있으며, 코드 변경 사항에 대한 추가적인 정보를 작성한다.
    본문은 반드시 설명 다음 빈 행으로 시작한다.
fix: prevent racing of requests

Introduce a request id and a reference to latest request. Dismiss
incoming responses other than from latest request.

Remove timeouts which were used to mitigate the racing issue but are
obsolete now.

Reviewed-by: Z
Refs: #123

Reference

profile
개발자 호소인

0개의 댓글