커밋 메세지 작성 가이드라인 - Conventional Commits

👋 Prologue

 개발자들이 코드를 작성하고 난 후 항상 고민에 빠지게 되는 순간이 있다. 바로 깃 커밋 메세지를 작성해야 할 때이다. 내가 작업한 내용을 한 문장으로 요약할 때 어떤 방식으로 써야하는지 헷갈리는 경우가 많다. 게다가 영어로 커밋을 작성하고자 할 때에는 영어 작문의 영역이 된다. 그러다보니 팀 프로젝트를 진행할 때, 규칙적이지 않는 커밋들이 쌓이게 되는 경우가 많아진다.

 이번 포스팅에서는 커밋 메세지 작성할 때 많은 개발자들이 사용하고 있는 방법에 대해서 알아볼 것이다. 협업을 할 때 서로가 작업한 내용에 대해 쉽게 이해할 수 있는 규칙적인 메세지를 작성하려면 어떻게 해야 할까?

 

📜 Conventional Commits

 Conventional Commits는 명확한 커밋 히스토리 관리를 위한 메세지 작성 규칙에 대해 제안하고 있다. 해당 규칙을 통해서 개발자와 컴퓨터 모두가 이해할 수 있는 커밋 메세지를 작성하는 것이 목표이다. 커밋 메세지의 규칙을 따라 작성할 경우, Semantic Versioning 관리에도 효과적이라고 한다.

Semantic Versioning은 어플리케이션 릴리즈 버전을 명시하는 형태로 2.1.0과 같은 3개의 숫자로 이루어져 있다. 각각 Major, Minor, Patch에 대한 버전을 의미한다.

 Conventional Commits에서 제안하는 메세지 작성 규칙은 다음과 같다.

structure

 커밋 메세지의 헤더는 필수적으로 작성되어야 하며, 작업 내용의 특징과 요약된 내용을 [ic]type[/ic]과 [ic]description[/ic]으로 명시해야 한다. 그 외에 적용 범위나 본문과 꼬리말은 선택적으로 작성하면 되고, Semantic Versioning에도 영향을 주지 않는다.

type

 커밋에 기록된 작업들의 성격이 무엇인지 알려주는 역할을 한다. 대표적으로 [ic]fix[/ic]와 [ic]feat[/ic]이 있으며, 앵귤러 컨벤션에서는 [ic]build[/ic], [ic]chore[/ic], [ic]ci[/ic], [ic]docs[/ic], [ic]style[/ic], [ic]refactor[/ic], [ic]perf[/ic], [ic]test[/ic] 등의 타입을 사용할 것을 권고하고 있다.

• fix : 버그 수정과 관련된 커밋 타입. Semantic Versioning의 Patch와 관련
• feat : 새로운 기능에 대한 커밋 타입. Semantic Versioning의 Minor와 관련
• build : 빌드 관련 파일 수정에 대한 커밋 타입
• chore : 분류하기 어려운 자잘한 수정에 대한 커밋 타입
• ci : CI 관련 수정에 대한 커밋 타입
• docs : Documentation 수정에 대한 커밋 타입
• style : 코드 의미에 영향을 주지 않는 수정에 대한 커밋 타입
• refactor : 코드 리팩토링에 대한 커밋 타입
• test : 테스트 코드 수정에 대한 커밋 타입

scope

 해당 커밋이 어떤 범위의 수정 사항인지 부가적인 설명을 하는 부분이다. 협업을 할 때에 작업을 분담해서 진행하기 때문에 범위에 대한 정보를 포함해서 커밋 메세지를 작업한다면 서로의 업무를 파악하는데 도움이 된다.

description

 해당 커밋의 작업 내용을 요약해서 적어야 한다. [ic]Add product detail information get method[/ic]와 같이 현재형 동사로 적는 것이 일반적이다.

body

[ic]type[/ic]과 [ic]description[/ic]으로 요약해서 전달하기 어려운 세부적인 내용에 대해서 적는 부분이다. Semantic Versioning에서 Major에 대한 수정이 일어난다면 [ic]body[/ic]를 작성하는 것이 필수적으로 요구된다.

footer

[ic]footer[/ic]는 해당 커밋이 어떤 이슈에서 왔는지와 같은 참조 정보들을 추가하는 용도로 사용한다. 또한, Semantic Versioning에서 Major한 변경이 있는 경우에 [ic]BREAKING CHANGE[/ic]라는 [ic]footer[/ic]를 작성하여 명시적으로 나타낸다. 즉, 어떠한 부분이 크게 변경되어 이전 버전과 다른 버전으로 명시해야 하는 경우에 해당 [ic]footer[/ic]를 작성한다고 보면 된다. [ic]BREAKING CHANGE[/ic]에 주의를 주기 위해서 커밋 헤더에서 [ic]![/ic]를 같이 표기하기도 한다.

 

📋 Examples

 Conventional Commits에서 규격이 적용된 예제 커밋 메세지들을 확인할 수 있다.

 

😀 Advantage with Covention

 컨벤션에 맞는 메세지를 작성하면 여러 가지 장점을 얻을 수 있다. 우선적으로, 규격화된 형식으로 작성되었기 때문에 CHANGELOG나 Semantic Version 관리를 자동적으로 할 수 있게 된다. 또한 커밋 메세지가 하나의 의미를 띄기 때문에, 단위 커밋 단위로 작업 내용에 대한 경계를 분명히 할 수 있다. 마지막으로 커밋 메세지만으로도 어떠한 내용인지 파악하는 것이 쉬워 다른 개발자와의 협업 및 소통에 큰 윤활 역할을 하게 된다.

 

📌 References

Conventional Commits

Semantic Versioning 2.0.0

Conventional Commit Messages

Git commit 메세지 규약 — Conventional Commits

 

블로그를 이전하며 리포스팅한 글입니다