(Git) 유구한 역사를 가진(?) 컨벤셔널 커밋

개발자들이라면 git commit 명령어를 날려보지 않은 사람은 없을 것이다.

 

 

git commit 명령어를 입력하고나면 나오는 창은 바로 커밋 메시지 입력 창이다.

 

 

이때마다 우리는 어떻게 작성해야하는지, Feat이라는 단어는 왜 쓰는 것이며, 어떨 때 fix를 사용하는지 등

 

 

뭔가 관습적이지만 출처 불분명한 규칙들로 커밋을 작성하곤 한다.(나만 그런가?)

 

 

그래서 도대체 이 커밋 문장은 어떻게 작성하는 것인지, 그 기준은 뭔지에 대해서 찾아보던 중 

 

 

Conventional Commits 규칙을 알게 되었고, 소개하려 한다.

(이미 나 빼고 다 아는 거 같지만)

 

 

 

🧐 Conventional Commits

---

source: bodybuilding.com

(컨벤셔널 데드리프트 아님, 하지만 같은 컨벤은 맞음)

 

컨벤셔널 커밋은 일종의 조약, 약속에 가깝다.

 

 

컨벤셔널 커밋을 이렇게 소개하고 있다.

 

Conventional Commits is a specification for adding human and machine-readable meaning to commit messages.

 

즉, 사람과 기계가 읽을 수 있는 의미를 커밋 메시지에 추가하기 위한 명세다.

 

 

 

잘 이해가 가지 않을 수 있다.

 

 

다음 구조를 보자.

 

<type>[optional scope]: <description>

[optional body]

[optional fotter(s)]

 

위의 골격을 바탕으로 커밋 메시지를 작성하는 것, 이것이 컨벤셔널 커밋이라고 할 수 있다.

 

 

Type에는 주로 다음과 같은 것들이 들어간다.

• feat: 코드 베이스에 새 기능이 추가 됐을 때(시멘틱 버전에서 MINOR에 해당)
• fix: 버그를 고쳤을 때(시멘틱 버전에서 PATCH와 같다.)
• docs: 문서가 변경되었을 때
• style: 코드 스타일이 변경되었을 때(세미콜론, 인덴트 등등)
• refactor: public API변경을 제외한 코드 리팩터링
• perf: 코드 성능 향상
• test: 존재하는 기능에 대한 테스트 추가
• chore: 사용자에게 영향을 주지 않는 무언가가 업데이트 되었을 때 

 

유의적 버전 2.0.0

 

그리고 저 타입을 사용해서 작성하면 아래와 같이 작성할 수 있다.

 

fix: correct minor typos in UserController

see the issue for details on the typos fixed #Optional

closes issue #12 #Optional

 

아래 두 줄은 선택사항이기 때문에 작성하지 않아도 무방하다.

 

 

🧐 그래서 뭐가 좋은데?

---

첫 번째로 이해도를 높일 수 있다.

 

구조적으로 나누어져 있음과 동시에, 더욱 상세하게 설명이 되어 있다.

 

type 덕분에 어떤 것에 관한 커밋인지 알 수 있고, 메시지와 본문 덕분에 상세한 내용을 알 수 있다.

 

 

 

두 번째로 변경 기록을 확인할 수 있다.

 

커밋 자체가 변경에 대한 상세한 기록이기 때문이다.

 

 

 

마지막으로 변경을 되돌릴 때 유리하다.

 

변경 사항을 되돌리거나 깃 충돌이 발생했을 때 쉽게 되돌릴 수 있다.

 

 

 

참고사이트

Conventional Commits

 

Conventional Commits