Table Of Contents

• TL;DR
• 0. 들어가기
• 1. Semantic Versioning(의미적 버전 관리)
  • 형식
    • 1. Major
    • 2. Minor
    • 3. Patch
    • pre-release
    • build metadata
  • 장점
• 2. Conventional Commits
  • 사용법
    • 1. type
    • 2. scope
    • 3. description
    • 4. body
    • 5. footer
    • 예시
  • 장점
• gitmoji
  • 사용법
  • 예시
• 참고

TL;DR

Conventional Commits 사용법

<type>[optional scope]: <description>

• type에는 fix / feat / BREAKING CHANGE 등 커밋의 내용을 짧게 설명한다.
• scope에는 해당 커밋이 적용되는 범위를 기술한다.
• description에는 변경 사항을 작성한다.
• 예시
  • fix: minor typos
  • feat(lang): added Korean translation
  • feat(seo): improve SEO of the website

0. 들어가기

처음으로 (업무를 제외한) 개발 팀 프로젝트를 하게 됐다🥹

팀원들과의 협업을 원활하게 하기 위해 일관성 있는 commit message 작성법을 알아보고자 한다!

가장 보편적으로 사용되는 commit message 규칙인 Conventional Commits, 그리고 gitmoji에 대해 알아보자.

Conventional Commits은 커밋 메세지에 커다란 변화, 신규 기능 추가, 문제 수정이 있음을 기술하는데, 이는 Semantic Versioning과 밀접하게 연결되어 있다. 따라서 Semantic Versioning에 대해 먼저 살펴보자.

1. Semantic Versioning(의미적 버전 관리)

의미적 버전 관리란, 소프트웨어 버전을 체계적으로 관리하기 위한 규칙이다.

예를 들어, v101처럼 사용하면 이번 버전에서 어떤 변경 사항이 있었는지 잘 드러나지 않지만, 5.3.1처럼 사용하면 변경 사항을 잘 전달할 수 있다.

형식

Major.Minor.Patch

버전 번호는 음이 아닌 정수를 사용한다.

1. Major

• 이전 버전과 호환되지 않는 변경 사항이 있을 때 Major 버전(주(主) 버전)을 올린다.
• 주버전 0.y.z는 초기 개발을 위해 사용하고, 1.y.z부터는 공개 api를 정의한다.

2. Minor

• 이전 버전과 호환되면서 새로운 기능을 추가할 때 Minor 버전(부(部) 버전)을 올린다.

3. Patch

• 이전 버전과 호환되면서 버그를 수정한 경우, Patch 버전(수(修) 버전)을 올린다.

pre-release

• 안정적인 release 이전에, 하이픈(-)을 이용해 표시해줄 수 있다.
  • 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92

build metadata

• patch 버전이나 정식배포 전 식별자 뒤에 더하기(+) 기호를 붙이고, 마침표로 구분한 식별자를 덧붙여 표현할 수 있다.
  • 1.0.0-alpha+001, 1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f85
• 빌드 메타데이터는 버전 우선순위를 계산할 때 고려하지 않는다.

장점

• 버전 번호를 통해서 변경 사항이 이전 버전과 호환되는지, 새로운 기능 추가인지, 단순 버그 수정인지 확인할 수 있다.
• 체계적인 방법으로 소프트웨어의 버전을 관리할 수 있다.

2. Conventional Commits

Conventional Commits은 명시적인 commit을 남기기 위한 규칙이다.

위에서 서술한 것처럼, Conventional Commits은 신규 기능 추가, 문제 수정, 커다란 변화가 있었음을 기술한다.

사용법

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

1. type

• 모든 commit은 명사로 된 type을 포함해야 한다.
• type의 자리에 올 수 있는 것들
• feat: commit에 새로운 기능이 추가될 때 사용한다. SemVer의 Minor와 관련이 있다.
• fix: 버그 수정을 하는 내용이 포함될 때 사용한다. SemVer의 Patch와 관련이 있다.
• Angular convention을 기반으로 하는 @commitlint/config-conventional에서는 다음과 같은 타입을 사용한다.
  • build: 빌드 시스템 속은 외부 종속성에 영향을 미치는 변경 사항(npm 등)
  • chore
  • ci: CI 설정 파일 혹은 스크립트의 변경 사항
  • docs
  • feat
  • fix
  • perf: 성능을 향상시키는 변경 사항
  • refactor: 버그 수정 및 기능 추가가 아닌 코드 변경 사항
  • revert
  • style: 코드의 의미에 영향을 미치지 않는 변경 사항(포매팅, 세미콜론 추가, 공백 등)
  • test: 테스트 추가
• BREAKING CHANGE: SemVer의 Major와 관련이 있다.
  • <type> 또는 [scope] 뒤에 !를 붙여 해당 commit이 기존 방식과 호환되지 않는 변화를 포함한다고 알려줄 수 있다.
  • 혹은 **BREAKING CHANGE:**로 시작하는 [footer]를 사용해 알려줄 수도 있다.
• 대/소문자 구분은 자유롭게 사용할 수 있고, 대신 일관된 규칙을 정해야 한다.

2. scope

• 변경 내용이 적용되는 영역을 기술하는 부분이다.
• 괄호(())로 감싸서 표현한다.
• 예시
  • 모듈이나 컴포넌트 이름
    • api, auth, Calendar
  • 파일이나 디렉토리
    • Readme.md, src/components/
  • 기능
    • login, search-bar
  • 버전 또는 패키지
    • react

3. description

• 변경 내용을 짧게 서술한다.
• 콜론(:) 뒤에 작성한다.

4. body

• 더 자세한 내용은 본문(body)에 작성할 수 있다.
• 본문은 자유로운 형식으로 작성할 수 있다. 빈 줄이 포함되어도 된다.
• 설명(description)과 본문(body) 사이에는 반드시 빈 줄이 있어야 한다.

5. footer

• footer는 <token>: <description>같은 형식으로 작성한다.
• token에서 띄어쓰기는 -을 사용한다.
  • 단, BREAKING CHANGE는 예외이다. (BREAKING CHANGE와 BREAKING-CHANGE는 같은 토큰으로 사용한다.)
  • i.e., Acked-by, Helped-by, Reference-to, See-also
• body와 footer 사이에도 빈 줄이 있어야 한다.

예시

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

• 첫 줄에서는 type, description만 사용하고 있다.
• 다음에는 빈 줄을 두고, body를 작성한다.
• body와 빈 줄로 구분하고, footer는 Reviewed-by라는 토큰과 Refs라는 토큰을 사용했다.

장점

• commit에서 어떤 의도로 변경이 이루어졌는지 명확하게 전달할 수 있어, 의사소통에 도움이 된다.
• commit history를 명확하게 알 수 있다.
• Release 노트를 작성하기 쉬워진다.

gitmoji

깃모지 역시 commit 메세지를 표준화하기 위한 규칙이다.

이모티콘을 사용하면 commit 목적이나 의도를 쉽게 알아볼 수 있다.

사용법

사용법은 Conventional Commits와 매우 유사하다. 각 부분에 대한 설명은 위를 참고하면 좋을 것 같다.

<intention> [scope?][:?] <message>

• intention: 이모지
• scope: (선택) 변경사항이 적용되는 범위
• message: 변경 사항에 대한 짧은 서술

예시

• gitmoji 명세에서 예시를 확인할 수 있다.
  • ⚡️ Lazyload home screen images.
  • 🐛 Fix onClick event handler
  • 🔖 Bump version 1.2.0
  • ♻️ (components): Transform classes to hooks
  • 📈 Add analytics to the dashboard
  • 🌐 Support Japanese language
  • ♿️ (account): Improve modals a11y

참고

• Semantic Versioning 2.0.0: https://semver.org
• Conventional Commits: https://www.conventionalcommits.org/en/v1.0.0/
• gitmoji: https://github.com/carloscuesta/gitmoji
• gitmoji: https://gitmoji.dev/