효율적인 commit message 작성을 위한 conventional commits

염정민
염정민
Jul 18, 2020 · 6 min read
Image for post
Image for post

안녕하세요 휴먼스케이프 개발자 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 변수는 더 이상 사용되지 않습니다.
Image for post
Image for post

conventional commits 장점

  • CHANGELOG를 자동으로 생성할 수 있습니다.
  • 프로젝트를 보는 사람이 변화를 쉽게 이해할 수 있습니다.
  • 빌드와 배포에 도움이 됩니다.

프로젝트에 적용하기

commitlint: helps your team adhering to a commit convention 를 활용하여 프로젝트 구성원이 조금 더 신뢰있게 사용할 수 있는 방법에 대해서 알아보겠습니다.

  1. 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를 설정하여 사용하고 있는데요.

Image for post
Image for post

위와 같이 commit template를 사용하게 되면 commit message 작성시에 구조와 요소를 알 수 있어 매우 편리합니다.

프로젝트를 효율적으로 관리하기 위한 방법들은 많습니다. 오늘은 그중 commit message 작성을 위한 conventional commits에 대해서 알아 보았습니다. 다음시간에 더 알찬내용으로 찾아뵙도록 하겠습니다. 감사합니다.

references

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

휴먼스케이프 기술 블로그

Together, we build healthier lives.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store