효율적인 commit message 작성을 위한 conventional commits
안녕하세요 휴먼스케이프 개발자 Jake 입니다.
프로젝트를 효율적으로 관리하기 위한 방법들은 여러가지가 있습니다.
그중에서도 소스코드 형상관리 프로그램( ex: git )은 필수라고 생각하는데요. 소스코드 형상관리 시스템 사용시에 commit message를 어떻게 적어야 할까 한번쯤은 고민 해보셨을 겁니다.
오늘은 commit message를 보다 명확하게 작업단위를 구분할 수 있도록 도와주는 conventional commits 에 대해 알아보도록 하겠습니다.
conventional commits 작성을 위한 commit message구조와 구성요소 는 아래와 같습니다.
구조
<타입>[적용 범위(선택 사항)]: <설명>
[본문(선택 사항)]
[꼬리말(선택 사항)]구성요소(<타입>, 본문, 꼬리말)
build: 시스템 또는 외부 종속성에 영향을 미치는 변경사항 (npm, gulp, yarn 레벨)
ci: ci구성파일 및 스크립트 변경
chore: 패키지 매니저 설정할 경우, 코드 수정 없이 설정을 변경
docs: documentation 변경
feat: 새로운 기능
fix: 버그 수정
perf: 성능 개선
refactor: 버그를 수정하거나 기능을 추가하지 않는 코드 변경, 리팩토링
style: 코드 의미에 영향을 주지 않는 변경사항 ( white space, formatting, colons )
test: 누락된 테스트 추가 또는 기존 테스트 수정
revert: 작업 되돌리기참고: Git Commit Msg
구성요소를 활용하여 commit message 구조를 작성할 때 알아두어야 할것(rules)에 대해서 알아보겠습니다.
- 모든 commit message는
<타입>[적용 범위(선택 사항)]: <설명>를 포함해야합니다. - <설명>은 타입쪽에 위치한 콜론뒤에 한개의 공백을 유지하고 작성되어야 합니다. ex)
<타입>[적용 범위(선택 사항)]: 여기부터 설명 작성이 가능합니다. - 본문(선택사항)을 작성할 경우에는 <설명> 사이에 빈행으로 구분이 되어있어야 합니다.
- 본문은 코드변경의 의도를 포함. 수정내역을 간단하게 볼 수 있어야 합니다.
- 꼬리말(선택사항)을 작성할 경우에는 <본문> 사이에 빈행으로 구분이 되어있어야 합니다.
- 프로그램의 단절적 변경이 있을 경우 <타입>뒤에 !로 표시하거나 꼬리말에 설명이 있어야 합니다.
- 단절적 변경에 대해 꼬리말로 설명할 경우 대문자 문자열 BREAKING CHANGE과 뒤따르는 콜론(:), 공백, 그리고 설명으로 구성되어야 합니다 ex) BREAKING CHANGE: api 스펙변경으로 인해 api/v2 설정값에 대해 보장하지 않습니다.
- conventional commit을 구성하는 정보의 단위는 반드시 대문자여야 하는 BREAKING CHANGE를 제외하고 구현자에 의해 대소문자를 구분하는 것으로 처리되어서는 안됩니다.
commit message 작성방법에 대해 알아보았으니 commit 을 작성하러 가볼까요?
예시)
[commit message example]
feat: 유저 전체 조회 기능 추가[commit message example]
fix!: update시 파라미터 수정
BREAKING CHANGE: deviceId 변수는 더 이상 사용되지 않습니다.
conventional commits 장점
- CHANGELOG를 자동으로 생성할 수 있습니다.
- 프로젝트를 보는 사람이 변화를 쉽게 이해할 수 있습니다.
- 빌드와 배포에 도움이 됩니다.
프로젝트에 적용하기
commitlint: helps your team adhering to a commit convention 를 활용하여 프로젝트 구성원이 조금 더 신뢰있게 사용할 수 있는 방법에 대해서 알아보겠습니다.
- install commitlint
npm install --save-dev @commitlint/{cli,config-conventional}
[package.json]
module.exports = {extends: ['@commitlint/config-conventional']};
2. install husky
npm install --save-dev husky[package.json]
{
"husky": {
"hooks": { "commit-msg": "commitlint -E
HUSKY_GIT_PARAMS"
}
}
}
위와 같이 설정하게 되면 git commit 시에 hooks를 통해 commit-msg를 검사하여 commit 여부를 결정 하게 됩니다.
옵션: commit template 만들기
저는 conventional commits 를 잘 사용하기 위해 fork의 commit template를 설정하여 사용하고 있는데요.
위와 같이 commit template를 사용하게 되면 commit message 작성시에 구조와 요소를 알 수 있어 매우 편리합니다.
프로젝트를 효율적으로 관리하기 위한 방법들은 많습니다. 오늘은 그중 commit message 작성을 위한 conventional commits에 대해서 알아 보았습니다. 다음시간에 더 알찬내용으로 찾아뵙도록 하겠습니다. 감사합니다.
references
- https://commitlint.js.org
- https://www.conventionalcommits.org
- https://ko.wikipedia.org/
- http://karma-runner.github.io/
Get to know us better!
Join our official channels below.
Telegram(EN) : t.me/Humanscape
KakaoTalk(KR) : open.kakao.com/o/gqbUQEM
Website : humanscape.io
Medium : medium.com/humanscape-ico
Facebook : www.facebook.com/humanscape
Twitter : twitter.com/Humanscape_io
Reddit : https://www.reddit.com/r/Humanscape_official
Bitcointalk announcement : https://bit.ly/2rVsP4T
Email : support@humanscape.io
