1.**BREAKING CHANGE:**`BREAKING CHANGE:`이라는 꼬리말을 가지거나 타입/스코프 뒤에 !문자열을 붙인 커밋은 단절적 API 변경(breaking API change) 있다는 것을 의미합니다 (이는 유의적 버전에서의 [`MAJOR`](http://semver.org/#summary)와 관련이 있습니다). 어떤 커밋 타입이라도 BREAKING CHANGE는 해당 커밋의 일부가 될 수 있습니다.
1.`fix:`와 `feat:` 이외의 다른 _타입_ 도 허용됩니다. 예를 들어 [앵귤러 컨벤션](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines)을 기반으로 하는 [@commitlint/config-conventional](https://github.com/conventional-changelog/commitlint/tree/master/%40commitlint/config-conventional)에서는 `build:`, `chore:`, `ci:`, `docs:`, `style:`, `refactor:`, `perf:`, `test:` 등의 타입을 사용할 것을 권고하고 있습니다.
1.`BREAKING CHANGE:<description>` 이외의 _꼬리말_ 을 규정 할 수 있으며 다음과 비슷한 컨벤션을 따를 수 있습니다. [git trailer format](https://git-scm.com/docs/git-interpret-trailers).
추가 타입들은 컨벤션 커밋 규격에 의해 의무화되지 않으며, 유의적 버전에 잠재적인 영향을 주지 않습니다(그것이 BREAKING CHANGE를 포함하지 않는 한).
<br/><br/>
추가적인 문맥 정보를 제공하기 위한 목적으로 사용되는 적용 범위는 커밋의 타입에 덧붙여질 수 있는데 괄호 안에 포함됩니다, 예를 들면, `feat(parser): add ability to parse arrays`.
<br/>
## 예제
### 설명과 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)에 주의를 주기 위해 `!`를 포함한 커밋 메세지
```
refactor!: drop support for Node 6
```
### BREAKING CHANGE 꼬리말과 `!`를 함께 포함한 커밋 메세지
```
refactor!: drop support for Node 6
BREAKING CHANGE: refactor to use JavaScript features not available in Node 6.
```
### 본문이 없는 커밋 메세지
```
docs: correct spelling of CHANGELOG
```
### 적용 범위를 가지는 커밋 메세지
```
feat(lang): add polish language
```
### 다중-단락 본문과 다수의 꼬리말을 가진 커밋 메세지
```
fix: correct minor typos in code
see the issue for details
on typos fixed.
Reviewed-by: Z
Refs #133
```
## 규격
이 문서에서 언급되는 주요 단어들인 “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, 그리고 “OPTIONAL”는 [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt)에 기술된 그대로 해석해야 합니다.
1. 모든 커밋은 `feat`, `fix` 같은 명사로 된 접두어를 포함해야 하고 그 뒤로 선택 사항인 적용 범위, 선택 사항인 `!`, 그리고 필수인 `:`과 공백이 있어야 합니다.
1.`feat` 타입은 커밋에 애플리케이션이나 라이브러리에 새로운 기능이 추가될 때 사용되어야 합니다.
1.`fix` 타입은 커밋에 애플리케이션의 버그 수정을 하는 내용을 포함하는 경우에 사용되어야 합니다.
1. 적용 범위는 타입 다음에 기술하는데 이는 코드베이스가 적용되는 영역을 기술하는 명사로 괄호로 감싸져야 합니다, 예를 들어, `fix(parser):`
1. 설명은 타입/적용 범위 접두어 뒤에 있는 콜론(:)과 공백 다음에 작성되어야 합니다. 설명은 코드 변경 사항에 대한 짧은 요약입니다, 예를 들어, _fix: array parsing issue when multiple spaces were contained in string._
1. 더 긴 커밋 본문은 짧은 설명 다음에 위치할 수 있으며 코드 변경 사항에 대한 추가적인 문맥적인 정보를 제공합니다. 본문은 반드시 설명 다음에 빈 행으로 시작해야 합니다.
1. 커밋 본문은 형식이 자유로우며 새 줄로 분리된 많은 수의 단락들로 구성 될 수 있습니다.
1. 하나 또는 다수의 꼬리말들은 본문 다음 빈 행 다음에 위치합니다. 각각의 꼬리말은 반드시 단어 토큰, 그 뒤에 `:<space>` 또는 `<space>#` 구분자, 그 뒤에 문자열 값으로 구성되어야 합니다(이것은 다음에 영향을 받았습니다 [git trailer convention](https://git-scm.com/docs/git-interpret-trailers)).
1. 꼬리말의 토큰은 반드시 공백 문자 대신 `-` 를 사용해야 합니다. 예를 들면 `Acked-by` (이것은 다중-단락 본문과 꼬리말 섹션을 구분하는데 도움이 됩니다). `BREAKING CHANGE`는 예외적으로 토큰으로 사용될 수 있습니다.
1. 꼬리말의 값은 공백이나 새 줄들을 포함할 수 있으며, 구문 분석기는 다음의 유효한 꼬리말 토큰/구분자 쌍을 관찰하면 반드시 종료해야 합니다.
1. 꼬리말로 포함된 경우 단절적 변경은 반드시 대문자 문자열 BREAKING CHANGE과 뒤따르는 콜론(:), 공백, 그리고 설명으로 구성되어야 합니다. 예를 들면 _BREAKING CHANGE: environment variables now take precedence over config files._
1. 타입/범위 접두어에 포함된 경우, 단절적 변경은 반드시 `:` 바로 앞의 `!` 를 명시해야 합니다. 만약 `!` 가 사용되면, `BREAKING CHANGE:` 는 꼬리말 섹션에서 생략할 수 있으며, 커밋 설명은 단절적 변경을 설명하기 위해 사용되어야 합니다.
한 가지 권장 사항은 `revert` 타입과 되돌려지는 커밋들의 SHA들을 참조하는 꼬리말를 사용하는 것입니다:
```
revert: let us never again speak of the noodle incident
Refs: 676104e, a215868
```
## About
Conventional Commits 규격은 [앵귤러 커밋 가이드라인](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines)에서 영감을 받았으며 이를 토대로 하고 있습니다.
이 규격의 첫 번째 초안은 아래 언급된 프로젝트에 기여하고 있는 분들과의 협업으로 작성되었습니다:
* [conventional-changelog](https://github.com/conventional-changelog/conventional-changelog): Git 히스토리에서 conventional commit 메시지를 구문 분석하기 위한 도구 모음.
* [bumped](https://bumped.github.io): 소프트웨어의 새 버전을 릴리즈하기 전후에 작업을 쉽게 수행할 수 있는 소프트웨어를 릴리즈하기 위한 도구.
* [unleash](https://github.com/netflix/unleash): 소프트웨어 릴리즈 및 배포 수명 주기를 자동화하기 위한 도구.
* [php-commitizen](https://github.com/damianopetrungaro/php-commitizen): Conventional Commits 규격에 따라 커밋 메시지를 생성하기 위해 사용되는 도구로 PHP 프로젝트에서 컴포저 의존성으로 구성 및 사용할 수 있거나 PHP 이외의 프로젝트에서 전 세계적으로 사용할 수 있습니다.
* [conform](https://github.com/autonomy/conform): Conventional Commits를 포함한 git 저장소에서 정책을 강제하는데 사용되는 도구.
* [standard-version](https://github.com/conventional-changelog/standard-version): GitHub의 스쿼시 버튼과 Conventional Commits 워크플로우를 이용한 자동 버전 지정 및 CHANGELOG 관리.
* [yargs](https://github.com/yargs/yargs): 모두가 가장 좋아하는 해적 테마의 커맨드 라인 인자 구문 분석기.
* [istanbuljs](https://github.com/istanbuljs/istanbuljs): 자바스크립트 테스트에 테스트 적용 범위를 추가하는 오픈 소스 도구 및 라이브러리 모음.
* [uPortal-home](https://github.com/UW-Madison-DoIT/angularjs-portal)와 [uPortal-application-framework](https://github.com/UW-Madison-DoIT/uw-frame): [Apereo uPortal](https://www.apereo.org/projects/uportal)을 향상시켜주는 옵션으로 추가 가능한 사용자 인터페이스.
* [massive.js](https://github.com/dmfay/massive-js): Node와 PostgreSQL을 위한 데이터 접근 라이브러리
* [electron](https://github.com/electron/electron): 자바스크립트, HTML, 그리고 CSS를 이용하여 크로스 클랫폼 데스크탑 앱을 만드는 프레임워크.
* [scroll-utility](https://github.com/LeDDGroup/scroll-utility): 사용하기 쉬운, 요소 중앙 정렬 및 부드러운 애니메이션을 위한 스크롤 유틸리티 패키지.
* [Blaze UI](https://github.com/BlazeUI/blaze): 프레임워크가 필요 없는 오픈소스 UI 툴킷.
* [Monica](https://github.com/monicahq/monica): 오픈 소스 개인 관계 관리 시스템.
* [mhy](https://mhy.js.org): 설정이 필요 없고 바로 사용 가능한 다목적 툴 박스와 개발 환경
