[SementicVersioning] Conventional Commits

 

[버전관리]시멘틱버저닝(Semantic Versioning) 란?

• 개요 :
  1. VCS(Version Controll System) 커밋 메시지에 곁들여진 가벼운 컨벤션으로 명확한 커밋 히스토리를 생성하기 위한 간단한 규칙을 제공.
  2. 본 규칙으로 만들어진 커밋 히스토리를 이용하여 더 쉽게 자동화된 도구를 만들 수 있음.
  3. 커밋 메시지에 신규 기능 추가, 문제 수정, 커다란 변화가 있음을 기술함으로써 유의적 버전(Sementic Versioning)과 일맥상통한 면이 있음.
• 사용 이유:
  1. 릴리즈노트 작성: CHANGELOG를 자동으로 생성하기 위함
  2. 이력관리(유의적버전 사용): 커밋의 타입을 기반으로 유의적 버전을 자동으로 변경하기 위함
  3. 의미 전달: 팀 동료, 타인, 그리고 기타 이해당사자에게 변화의 의미를 쉽게 전달.
  4. 빌드와 배포 프로세스 확립.
  5. 프로젝트 기여도 증가 : 더 구조화된 커밋 히스토리를 통해 인원별 프로젝트 이해도, 참여율, 기여도 증대.
• 구조 : 
• <type>(<scope>-선택사항): <descryption> [본문(선택사항)] [꼬리말(선택사항)]

간단 설명

• <type> 기본 요소 :
  1. fix(Bug Fixes): 코드베이스에서 버그를 패치하는 fix 타입 의 커밋 - PATCH
  2. feat(Features): 코드베이스에서 새 기능이 추가되는 feat 타입 의 커밋 - MINOR
  3. BREAKING CHANGE: BREAKING CHANGE: 이라는 꼬리말을 가지거나 <type>또는<scope> 뒤에 !문자열을 붙인 커밋은 단절적 API 변경(breaking API change) 있다는 것을 의미 - MAJOR
     • 어떤 커밋 타입이라도 BREAKING CHANGE는 포함 가능.
• <type> 추가 요소 : 앵귤러 컨벤션을 기반으로 하는 @commitlint/config-conventional의 권고 타입
  1. build(Builds): 빌드 관련 파일 수정에 대한 커밋 타입
  2. chore(Chores): 분류하기 어려운 자잘한 수정에 대한 커밋 타입
  3. ci(Continuous Integrations): CI 관련 수정에 대한 커밋 타입
  4. docs(Documentation): 문서 수정에 대한 커밋 타입
  5. style(Styles): 코드 의미에 영향을 주지 않는 수정에 대한 커밋 타입
  6. refactor(Code Refactoring): 코드 리팩토링에 대한 커밋 타입
  7. perf(Performance Improvements): 기능적 변경 없이 성능을 향상시키는 커밋
  8. test(Tests): 테스트 코드 수정에 대한 커밋 타입

2. 컨벤션 예제

1. MAJOR 사용 불가

• fix 타입 작성시 PATCH
• feat 타입 사용시 MINOR,
• fix, feat 외 타입 자체 판단 적용
• ❋ MAJOR 버전 사용 불가

---

1. 설명과 BREAKING CHANGE 꼬리말을 가리키는 커밋 메시지

feat: 제공된 구성 개체가 다른 구성을 확장하도록 허용

BREAKING CHANGE: 이제 구성 파일의 `extends` 키가 다른 구성 파일을 확장하는 데 사용됩니다.

2. 본문이 없는 커밋 메세지

docs: CHANGELOG의 철자 수정

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

feat(lang): 프랑스어 추가

4. 다중-단락 본문과 다수의 꼬리말을 가진 커밋 메세지

fix: request 충돌 방지

최신 요청이 아닌 수신 응답.

현재 쓸모가 없는 시간초과 응답에 대한 불필요 코드 제거

Reviewed-by: Z
Refs: #123

 

2. PATCH, MINOR 사용 불가

• <type>에 상관 없이 MAJOR 버전 적용
• ❋ PATCH, MINOR 사용 불가

---

1. 단절적 변경(breaking change)에 주의를 주기 위해 !를 포함한 커밋 메세지

feat!: 제품이 배송되면 고객에게 이메일을 보냅니다

2. 단절적 변경(breaking change))에 주의를 주기위해 적용 범위와 ! 를 포함한 커밋 메세지

chore!: Node 6에 대한 지원 중단

BREAKING CHANGE: Node 6에서 사용할 수 없는 JavaScript 기능을 사용하세요.

 

3. 규격 (* Conventional Commits 1.0.0 기준)

1. 모든 커밋은 feat, fix 같은 명사로 된 접두어를 포함해야 하고 그 뒤로 선택 사항인 적용 범위, 선택 사항인 !, 그리고 필수인 :과 공백이 있어야 합니다.
2. feat 타입은 커밋에 애플리케이션이나 라이브러리에 새로운 기능이 추가될 때 사용되어야 합니다.
3. fix 타입은 커밋에 애플리케이션의 버그 수정을 하는 내용을 포함하는 경우에 사용되어야 합니다. 4, 적용 범위는 타입 다음에 기술하는데 이는 코드베이스가 적용되는 영역을 기술하는 명사로 괄호로 감싸져야 합니다.
   • 예) fix(parser):
4. 설명은 타입/적용 범위 접두어 뒤에 있는 콜론(:)과 공백 다음에 작성되어야 합니다. 설명은 코드 변경 사항에 대한 짧은 요약입니다
   • 예) fix: array parsing issue when multiple spaces were contained in string.
5. 더 긴 커밋 본문은 짧은 설명 다음에 위치할 수 있으며 코드 변경 사항에 대한 추가적인 문맥적인 정보를 제공합니다. 본문은 반드시 설명 다음에 빈 행으로 시작해야 합니다.
6. 커밋 본문은 형식이 자유로우며 새 줄로 분리된 많은 수의 단락들로 구성 될 수 있습니다.
7. 하나 또는 다수의 꼬리말들은 본문 다음 빈 행 다음에 위치합니다. 각각의 꼬리말은 반드시 단어 토큰, 그 뒤에 :<space> 또는 <space># 구분자, 그 뒤에 문자열 값으로 구성되어야 합니다
   • 참고: git trailer convention
8. 꼬리말의 토큰은 다중-단락 본문과 꼬리말 섹션을 구분 하는데 도움을 줄 수 있도록 반드시 공백 문자 대신 - 를 사용해야 합니다.( * BREAKING CHANGE 예외적으로 사용 가능)
   • 예) Acked by:(X), Acked-by:(O), BREAKING CHANGE:(O)
9. 꼬리말의 값은 공백이나 새 줄들을 포함할 수 있으며, 구문 분석기는 다음의 유효한 꼬리말 토큰/구분자 쌍을 관찰하면 반드시 종료해야 합니다.
10. 단절적 변경은 반드시 커밋의 타입/적용범위 접두어에 표시하거나 꼬리말에 기입되어야 합니다.
11. 꼬리말로 포함된 경우 단절적 변경은 반드시 대문자 문자열 BREAKING CHANGE과 뒤따르는 콜론:, 공백, 그리고 설명으로 구성되어야 합니다.
    • 예) BREAKING CHANGE: environment variables now take precedence over config files.
12. 타입/범위 접두어에 포함된 경우, 단절적 변경은 반드시 : 바로 앞의 ! 를 명시해야 합니다. 만약 ! 가 사용되면, BREAKING CHANGE: 는 꼬리말 섹션에서 생략할 수 있으며, 커밋 설명은 단절적 변경을 설명하기 위해 사용되어야 합니다.
13. Conventional Commit을 구성하는 정보의 단위는 반드시 대문자여야 하는 BREAKING CHANGES를 제외하고 구현자에 의해 대소문자를 구분하는 것으로 처리되어서는 안됩니다.
14. BREAKING-CHANGE는 꼬리말에서 토큰으로 사용될 때 반드시 BREAKING CHANGE와 동의어야 합니다.