husky로 Conventional Commit 체크하기

😉 이번시간에는 Conventional Commit을 알아보고,
어떻게 husky로 Conventional Commit을 자동으로 체크할 수 있는지 그 방법을 알아보았다!

1. Conventional Commit이란

1) Conventional Commit은 무엇일까?

• Conventional Commits은 커밋 메시지에 대한 규칙이다.
• 이 규칙을 사용하면, 커밋 히스토리 추적은 물론 커밋의 성격도 쉽게 나타낼 수 있다.
• 아래는 커밋 메시지의 작성 형태이다.

// 기본 형태
<type>(<scope>)!: <short summary>

// 예시
fix(api): send an email to the customer when a product is shipped

2) 컨벤션 타입의 종류는?

• 커밋이 기능 추가인지 버그 수정인지 여부는 커밋 메시지의 타입 부분에서 명시할 수 있다.
• 타입을 fix로 지정하면 버그 수정 커밋을 의미하며, feat로 지정하면 기능 추가 커밋을 의미한다.
• 이외에도 여러가지 타입이 존재한다.

타입	설명
build	빌드 시스템, 외부 종속성에 영향을 주는 작업
ci	ci 구성 파일, 스크립트 변경
docs	md와 같은 documentation의 변경
feat	새로운 기능 추가
fix	버그 수정
perf	성능 개선 작업
refactor	리팩토링 작업(코드 동작은 유지하되, 코드의 가독성과 유지보수성을 높이기 위해 내부구조 변경)
test	테스트 코드 추가, 기존 테스트 수정
revert	커밋 취소

3) 컨벤션이 버저닝을 용이하게 한다?

• 버저닝에는 여러 방식이 있지만 그 중 유명한 것이 바로, Semenantic Versioning(SemVer)이다.
• SemVer은 유의미한 버저닝을 목표로 하며, 버전업을 어떤 기준을 해야하는지 규칙과 요구사항이 담긴 명세이다.

💡 그런데 SemVer과 Conveiontional Commit은 무슨 관계일까?

• SemVer을 하기 위해서는 작업의 특성에 따라 버저닝을 하는 게 좋다.
• 그런데 어떻게 작업의 특성을 구분할 수 있을까? 바로 커밋 메시지이다!
• 만약 우리가 커밋 규칙에 따라 메시지를 작성하면, 작업의 특성에 따라 유의미한 버저닝이 가능하다.
• 예를 들어, 버그 수정의 경우 타입을 fix로 정의하는데 이 타입을 인식하여 PATCH버전업을 하고,
• feat(기능 추가)의 경우, feat 타입을 인식하여 MINOR 버전업을 하는 것이다.

🤔 그런데 작업을 하다보면 실수로 잘못된 형식의 커밋 메시지를 작성할 수도 있는데,
커밋 메시지를 체크해주는 자동화 시스템은 없을까?
husky, git hook, commitlint를 이용하여 자동화하는 방법을 알아보자

2. Conventional Commit 자동화하기

1) 시작하기에 앞서…

• 우리는 husky, git hook, commitlint을 사용해 커밋 메시지 체크를 자동화할 것이다.
• 하지만 자동화에 앞서, 각각 무엇인지 우선 알아보자!

(1) git hook

• git에서 이벤트(commit, push 등) 발생 시 특정 스크립트를 실행시키는 기능이다.
• husky를 사용하면 git hook 스크립트를 제어할 수 있게 도와준다.
• husky 대신 .git/hooks폴더에서 스크립트를 작성할 수 있으나, 이 경우 git에 기록이 남지 않는 단점이 있다.

(2) husky

• husky는 git hook를 제어할 수 있는 npm 라이브러리이다.

(3) commitlint

• commitlint는 커밋 컨벤션이 지켜졌는지 체크해주는 기능이다.

💡 결국 우리는 husky로 commit-msg훅에서 commitlint를 동작시키는 스크립트가 필요하다!

2) 적용해보기

😊 yarn을 기반으로 커밋 메시지 컨벤션을 자동 체크해주는 시스템을 만들어보자! (예시는 github에 레포를 만들고 clone했다는 과정하에 진행)

(1) 프로젝트 환경 구축하기

• 명령어를 사용해 yarn 기본 설정을 해준다.
• 실행을 해주면 프로젝트에 package.json이 생긴다.

yarn init

(2) husky 설정하기

• 만약 본인 yarn 버전이 1인 경우, 아래 명령어를 사용해 husky 설치는 물론 기본 셋팅을 할 수 있다.

npx husky-init && yarn

• 명령어 결과, .husky 폴더와 package.json에 prepare 명령어가 자동 추가된다.

🤔 어? 왜 husky가 devDependencies에 추가된걸까?

• devDependencies에 설치된 라이브러리는 배포에 포함되지 않기에 불필요한 빌드 시간을 줄일 수 있다.
• husky의 경우 개발시에만 필요하고 앱 동작에는 직접적인 연관이 없기에 devDependencies에 추가되는 것이다.

(3) commitlint 설정하기

• @commitlint/cli, @commitlint/config-conventional를 설치한다.

yarn add -D @commitlint/cli @commitlint/config-conventional

• 루트 디렉토리에 commitlint.config.js 파일을 추가해준다.

// commitlint.config.js

module.exports = { extends: ['@commitlint/config-conventional'] };

(4) commit-msg hook 적용하기

• commit-msg 훅은 커밋이 완료 전에 프로젝트 상태나 커밋 메시지를 검증할 때 사용한다.
• 아래husky 명령어를 사용해, commit-msg 훅에 npx --no-install commitlint --edit $1 스크립트를 추가해주었다.

npx husky add .husky/commit-msg 'npx --no-install commitlint --edit $1'

• 이렇게 하면, husky가 commit-msg 훅에서 commitlint 명령어를 실행하게 된다.

(5) 테스트해보기

🎊 설정도 다 했겠다! 메시지 체크가 잘되는지 확인해보자

• 우선, 커밋 컨벤션에 맞지않는 형식으로 메시지를 작성하고 커밋을 해보았다.

• 그러면 아래와 같은 에러 화면이 등장한다. Show Command Output을 클릭해보면,

• 에러가 발생한 input과 어떤 부분이 문제인지 출력문에서 확인할 수 있다. (완성!)

이번시간에는 Conventional Commit의 개념과 husky로 Conventional Commit를 자동 체크하는 방법도 알아보았다. 해당 포스팅에서는 commit-msg 훅을 이용해 컨벤션 체크만 했지만 pre-commit 훅에서 다른 lint도 같이 체크할 수도 있다. husky를 이용하면 여러가지 git hook을 제어할 수 있으니, 다른 것도 한 번 자동화해보는 건 어떨까?