Git 커밋 메시지를 더 좋게 만들기

오픈 소스 프로젝트에서 멋진 커밋 메시지를 만드는 방법이 궁금하십니까? git commit 메시지를 더 좋게 만드는 방법은 다음과 같습니다.
나는 Angular의 열렬한 팬이며 특정 패턴을 발견한 프로젝트의 기여 지침을 파고 들었고 간단한 검색 후 conventional commits이라는 지침을 발견했습니다.

A specification for adding human and machine readable meaning to commit messages

그래서 여기 뭐가 특별해?

아이디어는 표준 사양을 사용하여 커밋 메시지를 구성하는 것이며 커밋 메시지는 다음과 같습니다.

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

커밋에는 라이브러리 소비자에게 의도를 전달하기 위한 다음과 같은 구조적 요소가 포함되어 있습니다.

수정: 수정 유형의 커밋은 코드베이스의 버그를 패치합니다(시맨틱 버전 관리의 PATCH와 관련됨).

feat: 유형 feat의 커밋은 코드베이스에 새로운 기능을 도입합니다(시맨틱 버전 관리에서 MINOR와 관련됨).

BREAKING CHANGE: 바닥글 BREAKING CHANGE:가 있거나 ! 유형/범위 뒤에는 주요 API 변경이 도입됩니다(시맨틱 버전 관리의 MAJOR와 관련됨). BREAKING CHANGE는 모든 유형의 커밋의 일부가 될 수 있습니다.

fix: 및 feat: 이외의 유형이 허용됩니다. 예를 들어 @commitlint/config-conventional(Angular 규칙 기반)은 build:, chore:, ci:, docs:, style:, refactor:, perf를 권장합니다. :, 테스트: 및 기타.

BREAKING CHANGE 이외의 바닥글: 제공될 수 있으며 git trailer 형식과 유사한 규칙을 따를 수 있습니다.

추가 유형은 Conventional Commits 사양에서 요구하지 않으며 시맨틱 버전 관리에 암시적 영향을 미치지 않습니다(주요 변경 사항을 포함하지 않는 한). 범위는 추가 컨텍스트 정보를 제공하기 위해 커밋 유형에 제공될 수 있으며 괄호 안에 포함됩니다(예: feat(parser): 배열을 구문 분석하는 기능 추가).

이제 이것을 사용해야 하는 이유는 무엇입니까? …

CHANGELOG를 자동으로 생성합니다.

시맨틱 버전 범프를 자동으로 결정합니다(달성된 커밋 유형에 따라).

변경 사항의 특성을 팀원, 대중 및 기타 이해 관계자에게 전달합니다.

빌드 및 게시 프로세스 트리거.

사람들이 보다 구조화된 커밋 기록을 탐색할 수 있도록 하여 프로젝트에 보다 쉽게 ​​기여할 수 있도록 합니다.

코드를 병합하고 새로운 사람들을 팀에 합류시키는 동안 내 인생을 쉽게 만들었습니다.

행복한 코딩!!