깃허브에 commit을 남길 때, 다들 어떤 식으로 남기는가? 자신만의 규칙이 있는가? 아님 그냥 되는대로, 느낌대로?
나의 경우는 "느낌"대로 올리는 것 같다. 물론 commit에는 내가 올린 기능에 대한 설명을 남기는 부분이지만, 그 "규칙"이라는 것에서는 느낌대로 올린다.
이때, 사실 commit를 올리는 것에 정답은 없다. 그러나 일정한 프로덕트를 만드는 프로젝트에서는 이 commit 규칙이 필요하게 된다. (뿐만 아니라 깃 협업의 흐름도 정해져야 한다.)
이때 쓰이는 스펙이 "conventional commits"이다.
conventional commits 이란?
일단 공식 문서의 링크는 다음과 같다.
https://www.conventionalcommits.org/en/v1.0.0/
Conventional Commits
A specification for adding human and machine readable meaning to commit messages
www.conventionalcommits.org
Conventional Commits는 명확한 커밋 히스토리 관리를 위한 메시지 작성 규칙에 대해 제안하고 있다. 해당 규칙을 통해서 개발자와 컴퓨터 모두가 이해할 수 있는 커밋 메시지를 작성하는 것이 목표이다. 즉, conventional commits는 일종의 커밋 규칙이라고 할 수 있다. 이것을 적극적으로 채택하는 곳 중 하나가 토스이다.
Conventional Commits에서 제안하는 메세지 작성 규칙은 다음과 같다.
structure
커밋 메세지의 헤더는 필수적으로 작성되어야 하며, 작업 내용의 특징과 요약된 내용을 type과 description으로 명시해야 한다. 그 외에 적용 범위나 본문과 꼬리말은 선택적으로 작성하면 되고, Semantic Versioning에도 영향을 주지 않는다.
type
커밋에 기록된 작업들의 성격이 무엇인지 알려주는 역할을 한다. 대표적으로 fix와 feat이 있으며, 앵귤러 컨벤션에서는 build, chore, ci, docs, style, refactor, perf, test 등의 타입을 사용할 것을 권고하고 있다.
- fix : 버그 수정과 관련된 커밋 타입. Semantic Versioning의 Patch와 관련
- feat : 새로운 기능에 대한 커밋 타입. Semantic Versioning의 Minor와 관련
- build : 빌드 관련 파일 수정에 대한 커밋 타입
- chore : 분류하기 어려운 자잘한 수정에 대한 커밋 타입
- ci : CI 관련 수정에 대한 커밋 타입
- docs : Documentation 수정에 대한 커밋 타입
- style : 코드 의미에 영향을 주지 않는 수정에 대한 커밋 타입
- refactor : 코드 리팩토링에 대한 커밋 타입
- test : 테스트 코드 수정에 대한 커밋 타입
scope
해당 커밋이 어떤 범위의 수정 사항인지 부가적인 설명을 하는 부분이다. 협업을 할 때에 작업을 분담해서 진행하기 때문에 범위에 대한 정보를 포함해서 커밋 메시지를 작업한다면 서로의 업무를 파악하는데 도움이 된다.
description
해당 커밋의 작업 내용을 요약해서 적어야 한다. Add product detail information get method와 같이 현재형 동사로 적는 것이 일반적이다.
body
type과 description으로 요약해서 전달하기 어려운 세부적인 내용에 대해서 적는 부분이다. Semantic Versioning에서 Major에 대한 수정이 일어난다면 body를 작성하는 것이 필수적으로 요구된다.
footer
footer는 해당 커밋이 어떤 이슈에서 왔는지와 같은 참조 정보들을 추가하는 용도로 사용한다. 또한, Semantic Versioning에서 Major한 변경이 있는 경우에 BREAKING CHANGE라는 footer를 작성하여 명시적으로 나타낸다.
즉, 어떠한 부분이 크게 변경되어 이전 버전과 다른 버전으로 명시해야 하는 경우에 해당 footer를 작성한다고 보면 된다. BREAKING CHANGE에 주의를 주기 위해서 커밋 헤더에서 !를 같이 표기하기도 한다.
📋 Examples
Conventional Commits에서 규격이 적용된 예제 커밋 메세지들을 확인할 수 있다.
😀 Advantage with Covention
컨벤션에 맞는 메세지를 작성하면 여러 가지 장점을 얻을 수 있다. 우선적으로, 규격화된 형식으로 작성되었기 때문에 CHANGELOG나 Semantic Version 관리를 자동적으로 할 수 있게 된다.
또한 커밋 메세지가 하나의 의미를 가지기 때문에, 단위 커밋 단위로 작업 내용에 대한 경계를 분명히 할 수 있다. 마지막으로 커밋 메시지만으로도 어떠한 내용인지 파악하는 것이 쉬워 다른 개발자와의 협업 및 소통에 큰 윤활 역할을 하게 된다.
참고한 티스토리글
커밋 메세지 작성 가이드라인 - Conventional Commits
👋 Prologue 개발자들이 코드를 작성하고 난 후 항상 고민에 빠지게 되는 순간이 있다. 바로 깃 커밋 메세지를 작성해야 할 때이다. 내가 작업한 내용을 한 문장으로 요약할 때 어떤 방식으로 써야
tedjunny.tistory.com
https://1minute-before6pm.tistory.com/66
Conventional Commits: 커밋 메시지 작성을 위한 가이드
커밋 메시지의 중요성 먼저, 커밋 메시지가 왜 중요한지를 이해해야 합니다. 커밋 메시지는 단순히 코드 변경 사항을 추적하는 것 이상의 역할을 합니다. 커밋 메시지는 사람들이 왜 그런 변경
1minute-before6pm.tistory.com
'깃&깃허브' 카테고리의 다른 글
| 깃 특정 부분 add 하는 방법 (0) | 2025.04.02 |
|---|---|
| 깃허브 포크 (Fork)하는 방법 (0) | 2025.04.01 |
| 깃허브 ReadMe.md에 이미지 올리는 법 (0) | 2025.02.07 |
| 깃허브 라이센스 추가하는 방법 (0) | 2025.02.07 |
| 깃허브 - REDEME 꾸미기 (0) | 2024.11.22 |
