Conventional commit

우리는 많은 협업과 프로젝트들을 진행하면서 git을 사용하게 되는데, 물론 우리 팀원끼리 혹은 아는 사람끼리만 쓸 수도 있지만 오픈소스로 공개하면 다양한 사람들이 볼 수 도 있다. 

내가 어떤 작업을 했는지를 간단명료하게 남기려고 보통 commit message를 남기는데, 이러한 것도 기본적인 형식이 있다고한다. 명시적으로 정해져있는 것은 아니지만, 이 conventional commit이라는 방법을 이용하여 일관되게 올리면 나중에 알아보기도 편하고 모르는 사람이 봐도 한눈에 이해할 수 있다.

한번만 습관을 들여놓으면 편하기 때문에 아직 git에 익숙하지 않은 지금 배워보고자 한다.

 

Conventioanl commit의 장점

• CHANGELOG를 자동적으로 생성할 수 있다.
• 커밋의 종류에 따라 의미론적 버전 증가를 자동으로 결정할 수 있다.
• 팀원, 공개적인 사용자, 그리고 다른 이해 관계자들에게 변화의 성격을 알리는데 도움이 된다.
• 빌드와 배포 프로세스를 트리거하는데 활용할 수 있다.
• Semantice versioning을 쉽게하게 해준다.
• 사람들이 프로젝트에 더 쉽게 기여할 수 있도록 해주며, 이는 더 구조화된 커밋 히스토리를 탐색할 수 있게 해준다

 

 우선 틀은 아래와 같다.

기본 구조

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

기본적인 구조는 subjcet(제목), body(본문), footer(꼬리말)로 나눈다.

Commit type

제일 중요한 것이 type과 subject을 작성할 때인데,우선 type부터 알아보자.

Type

• fix: 버그를 수정하는 커밋
• feat: 새로운 기능을 추가하는 커밋
• build:: 빌드 시스템 또는 외부 종속성에 대한 변경사항. 예: gulp, broccoli, npm
• chore:: 코드나 테스트를 수정하지 않는 일반적인 작업.
• ci:: CI 설정 파일 및 스크립트를 변경합니다. 예: Travis, Circle 등
• docs:: 문서 변경
• style:: 코드의 스타일을 변경. (white-space, formatting, missing semi colons 등)
• refactor:: 버그를 수정하거나 새로운 기능을 추가하지 않는 코드 수정을 나타냅니다.
• perf:: 성능을 향상시키는 코드 변경을 나타냅니다.
• test:: 누락된 테스트 추가 또는 기존 테스트 수정을 나타냅니다
• BREAKING CHANGE: 해당 이라는 꼬리말을 가지거나 타입/스코프 뒤에 !문자열을 붙인 커밋은 단절적 API 변경(breaking API change) 있다는 것을 의미

이렇게 제일 앞에 어떤한 것에 대한 commit인지를 의미하는 type을 적어줘야하며, 

breaking change(이것으로 인해 지금까지 작동되던 것이 안된다던가 하는 단절적이슈)가 있을 경우 각 type뒤에 !를 붙여주면 된다.  또한 scope라고 되어있는것은 필수는 아니지만, 어떤 범위에 해당하는 수정인지 등을 적어주는 것이다 .

# 예시 1
feat: allow provided config object to extend other configs

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

# 예시 2
feat!: send an email to the customer when a product is shipped

# 예시 3
feat(api)!: send an email to the customer when a product is shipped

description

type: 뒤에 적는 subjcet에도 규칙이 있다. 이는 commit메시지가 짤리거나, 한눈에 알아볼 수 있도록 정해진 약속이다.

• 제목은 최대 50글자가 넘지 않도록 하고 마침표 및 특수기호는 사용하지 않는다.
• 영문으로 표기하는 경우 동사(원형)를 가장 앞에 두고 첫 글자는 대문자로 표기한다.(과거 시제를 사용하지 않는다.)
• 제목은 개조식 구문으로 작성한다. --> 완전한 서술형 문장이 아니라, 간결하고 요점적인 서술을 의미.

다음으로 body에 대하여 알아보자.

Body

body의 경우에도 규칙이 있는데, body는 필수적으로 적지는 않아도 된다. subjcet만으로 설명하기 부족하거나 더 상세한 내용들을 기록할 때 적는다.

• 본문은 한 줄 당 72자 내로 작성
• 본문 내용은 양에 구애받지 않고 최대한 상세히 작성
• 본문 내용은 How 보다 What과 WHY에 초점을 맞추어 작성

Footer

꼬리말의 경우에도 규칙이 있는데 이것도 일반적인 상황에서는 필수가 아니지만, 특정한 상황들에서는 적어줘야 한다.

• 이슈 트래커 ID를 작성
• 꼬리말은 "유형: #이슈 번호" 형식으로 사용한다.
• 여러 개의 이슈 번호를 적을 때는 쉼표(,)로 구분한다.
• 이슈 트래커 유형은 다음 중 하나를 사용한다.
  - Fixes: 이슈 수정중 (아직 해결되지 않은 경우)
  - Resolves: 이슈를 해결했을 때 사용
  - Ref: 참고할 이슈가 있을 때 사용
  - Related to: 해당 커밋에 관련된 이슈번호 (아직 해결되지 않은 경우)
  ex) Fixes: #45 Related to: #34, #23

 

더 자세한 conventional commits에 대하여 작성된 글은 아래를 참조하면 된다.

다음 글에서는 이러한 conventional commits를 이모지와 함께 좀 더 편리하게 작성할 수 있는 법을 알아보겠다.

Conventional Commits