깃 커밋 메시지 컨벤션 (Git Commit Message Convention)

남양주개발자

·

2020. 11. 20. 08:00

728x90
반응형

깃 커밋 메시지 컨벤션 (Git Commit Message Convention), 깃 커밋 메시지 제대로 알고 작성하자!

회사에서 팀 단위로 개발을 진행하거나 개인 토이 프로젝트를 하다보면 자연스럽게 Git과 같은 버전 관리 시스템을 사용하게 됩니다. 버전 관리 시스템을 사용한다면 특정 시점에 작업자의 수정사항이나 추가사항들을 명시하고 저장을 하는 행위인 커밋(commit)을 해야하죠.

하지만 바쁘다는 핑계로 또는 정말 단순히 컨벤션을 모른다는 이유로 커밋 메시지 작성을 소홀히 하지 않으셨나요? 저또한 회사에서 팀 동료들과 좀 더 긴밀하게 협업하기 위해 굉장히 기본적인 부분인 커밋 메시지 컨벤션부터 점검하고자 합니다.

커밋 메시지 컨벤션은 유다시티 커밋 메시지 컨벤션을 참고했고, 앞으로 커밋 메시지를 작성할 때 좋은 가이드가 될 수 있으니 참고해주시면 좋을 것 같습니다.

 

Udacity Nanodegree Style Guide

Introduction This style guide acts as the official guide to follow in your projects. Udacity evaluators will use this guide to grade your projects. There are many opinions on the "ideal" style in the world of development. Therefore, in order to reduce the

udacity.github.io

기본 컨셉

type: subject

body

footer

타입

타입은 타이틀 내에 포함되고, 커밋 타입은 아래의 타입들 중 하나로 구성됩니다.

 

  • feat : 새로운 기능 추가 (a new feature)
  • fix : 버그 수정 (a bug fix)
  • docs : 문서 수정 (changes to documentation)
  • style : 코드 포맷팅, 세미콜론 누락, 코드 변경이 없는 경우 (formatting, missing semi colons, etc; no code change)
  • refactor : 코드 리펙토링 (refactoring production code)
  • test : 테스트 코드, 리펙토링 테스트 코드 추가 (adding tests, refactoring test; no production code change)
  • chore : 빌드 업무 수정, 패키지 매니저 수정 (updating build tasks, package manager configs, etc; no production code change)

제목(Subject)

제목은 50자를 넘기지 않고, 문장의 끝에 마침표를 넣지 않습니다. 커밋 메시지에는 과거시제를 사용하지 않고, 명령어로 작성하도록 합니다.

// 타이틀 예시
feat: Summarize changes in around 50 characters or less

본문(Body)

커밋 본문 내용은 선택사항이기 때문에 모든 커밋에 본문 내용을 작성할 필요는 없습니다. 타이틀 외에 추가적으로 정보를 전달하고 싶을 경우 본문에 추가적인 정보를 기입하시면 됩니다.

푸터(Footer)

푸터도 본문과 같이 선택 사항이며 보통 이슈를 추적하기 위해 이슈 ID를 넣어주는 용도로 사용합니다.

커밋 메시지 예시

아래는 유다시티 커밋 메시지 컨벤션에서 제공해주는 메시징 예시입니다.

feat: Summarize changes in around 50 characters or less // 타이틀

// 본문
More detailed explanatory text, if necessary. Wrap it to about 72
characters or so. In some contexts, the first line is treated as the
subject of the commit and the rest of the text as the body. The
blank line separating the summary from the body is critical (unless
you omit the body entirely); various tools like `log`, `shortlog`
and `rebase` can get confused if you run the two together.

Explain the problem that this commit is solving. Focus on why you
are making this change as opposed to how (the code explains that).
Are there side effects or other unintuitive consequenses of this
change? Here's the place to explain them.

Further paragraphs come after blank lines.

 - Bullet points are okay, too

 - Typically a hyphen or asterisk is used for the bullet, preceded
   by a single space, with blank lines in between, but conventions
   vary here

If you use an issue tracker, put references to them at the bottom,
like this:

// 푸터
Resolves: #123
See also: #456, #789

실제 사용 예시

feat: 상세페이지 ThumbnailList 컴포넌트에 무한 스크롤 추가

2020.04.05 x님의 기획 요구사항 변경으로 인해 상세페이지 ThumbnailList 컴포넌트 기능 변경
모바일 버전에서 페이지네이션 방식에서 무한 스크롤 방식으로 기능 변경
  - vue-infinitet-scroll@2.3.0 라이브러리 추가

Resolves: #231

정리

이번 포스팅에서 개발할 때 필수적으로 사용하는 버전 관리 시스템인 Git에서 Commit 메시지를 좀 더 명시적으로, 체계적으로 작성하는 커밋 메시지 컨벤션에 대해서 다뤄봤습니다. 혼자 개발을 해도 어떤 시점에 어떤 수정사항이 있는지 명시적으로 남기지 않는다면 잊어버리기 마련이고, 수정하고 싶은 부분을 찾기도 쉽지 않을 것입니다. 혼자 개발해도 관리가 안되는데 팀 단위로 정해진 컨벤션없이 관리를 한다면 훨씬 더 관리가 되지 않겠죠?

이제는 커밋 메시지 컨벤션을 맞춰 커밋 메시지를 작성함으로써 좀 더 체계적으로 협업을 할 수 있는 환경을 만들어보는 것은 어떨까요!

728x90
반응형
그리드형

이 포스팅은 쿠팡파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.

💖 저자에게 암호화폐로 후원하기 💖

아이콘을 클릭하면 지갑 주소가자동으로 복사됩니다