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

안녕하세요.🐱‍🐉 오늘은 Git 커밋 메시지 작성법에 대해 정리해볼게요.
Udacity Git Commit Message Style Guide를 참고하여 작성했어요~!

---

커밋 메시지, 왜 중요할까?

자바 스프링의 예전 커밋 로그를 보자.

$ git log --oneline -5 --author cbeams --before "Fri Mar 26 2009"

e5f4b49 Re-adding ConfigurationPostProcessorTests after its brief removal in r814. @Ignore-ing the
testCglibClassesAreLoadedJustInTimeForEnhancement() method as it turns out this was one of the
culprits in the recent build breakage. The classloader hacking causes subtle downstream effects,
breaking unrelated tests. The test method is still useful, but should only be run on a manual basis
to ensure CGLIB is not prematurely classloaded, and should not be run as part of the automated build.

2db0f12 fixed two build-breaking issues: + reverted ClassMetadataReadingVisitor to revision 794
+ eliminated ConfigurationPostProcessorTests until further investigation determines why it causes
downstream tests to fail (such as the seemingly unrelated Class PathXmlApplicationContextTests)

147709f Tweaks to package-info.java files

22b25e0 Consolidated Util and MutableAnnotationUtils classes into existing AsmUtils

7f96f57 polishing

읽기 싫다.

이게 중요한게 아니니... 시간이 지난 뒤 작성된 커밋 로그를 다시 보면?

$ git log --oneline -5 --author pwebb --before "Sat Aug 30 2014"

5ba3db6 Fix failing CompositePropertySourceTests

84564a0 Rework @PropertySource early parsing logic

e142fd1 Add tests for ImportSelector meta-data

887815f Update docbook dependency and generate epub

ac8326d Polish mockito usage

당연히 아래쪽이 간결하고 일관성 있으며 전달하려는 바가 명확하다. 이유가 뭘지 생각해본다면 당연할 듯싶다.
간결하고 읽기 쉬운 커밋 메시지는 나를 포함한 개발자에게 변경사항을 빠르게 전달하는데 큰 도움이 된다. 쓰자.

---

커밋 메시지 (Commit Message)

커밋 메시지는 아래와 같이 제목/본문/꼬리말의 구조로 작성합니다.

type: Subject (제목)

body (본문)

footer (꼬리말)

Type
feat : 새로운 기능
fix : 버그 수정
docs : 문서 변경
style : 서식, 세미콜론 누락 등, 코드 변경 없음
refactor : Refactoring code
test : 테스트 추가, 리팩터링 테스트, Production Code(실제로 사용하는 코드) 변경 없음
chore : 빌드 작업, 패키지 관리자 구성 등 업데이트, Production Code 변경 없음

The Subject
- 50자 이하, 대문자로 시작하여 작성하고, 마침표로 끝내지 않는다.
- 명령문으로 작성한다.
- 이렇게 작성하는 이유는 Git이 사용하는 메시지 형식을 맞춰 일관된 로깅을 위해.
(Merge나 Update 등을 보면 알 수 있다.)

The Body
- 72자 이하, 설명이 필요한 경우에만 작성한다. 코드 변경의 이유를 명확히 작성할수록 좋다.
- 어떻게 보다는 무엇을, 왜 하는지 설명한다.

The Footer
- 선택사항이며, issue tracker ID를 참조하는 데 사용한다. 남겨주는 게 좋다.


자주 사용되는 Type 예시

Fix : 버그 수정
Fix my test
Fix typo in style.css
Fix my test to return undefined
Fix error when using my function

Update : Fix와 달리 원래 정상적으로 동작했지만 보완의 개념
Update harry-server.js to use HTTPS

Add
Add documentation for the defaultPort option
Add example for setting Vary: Accept-Encoding header in zlib.md

Remove(Clean이나 Eliminate) : ‘unnecessary’, ‘useless’, ‘unneeded’, ‘unused’, ‘duplicated’가 붙는 경우가 많음
Remove fallback cache
Remove unnecessary italics from child_process.md

Refactor : 리팩토링

Simplify : Refactor와 유사하지만 약한 수정, 코드 단순화

Improve : 호환성, 테스트 커버리지, 성능, 검증 기능, 접근성 등의 향상
Improve iOS's accessibilityLabel performance by up to 20%

Implement : 코드 추가보다 큰 단위의 구현
Implement bundle sync status

Correct : 주로 문법의 오류나 타입의 변경, 이름 변경 등에 사용
Correct grammatical error in BUILDING.md

Prevent
Prevent hello handler from saying Hi in hi.js

Avoid : Prevent는 못하게 막지만, Avoid는 회피(if 등)
Avoid flusing uninitialized traces

Move : 코드나 파일의 이동
Move function from header to source file

Rename : 이름 변경
Rename node-report to report

 

Example

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 consequences 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

 

---

Git config에 message template 추가

Git Bash를 이용해보자.

.gitconfig 파일에 commit.template 항목 기본 값으로 등록할 내용을 추가한다.

git config --global commit.template ~/.gitmessage

명령을 실행하면 .gitconfig 파일에 다음과 같이 설정된다.

[commit]
  template = ~/.gitmessage

~/.gitmessage에 내용을 작성한다.

# <type>: <subject>
##### Subject 50 characters ################# -> |


# Body Message
######## Body 72 characters ####################################### -> |

# Issue Tracker Number or URL

# --- COMMIT END ---
# Type can be
#   feat    : new feature
#   fix     : bug fix
#   refactor: refactoring production code
#   style   : formatting, missing semi colons, etc; no code change
#   docs    : changes to documentation
#   test    : adding or refactoring tests
#             no productin code change
#   chore   : updating grunt tasks etc
#             no production code change
# ------------------
# Remember me ~
#   Capitalize the subject line
#     제목줄은 대문자로 시작한다.
#   Use the imperative mood in the subject line
#     제목줄은 명령어로 작성한다.
#   Do not end the subject line with a period
#     제목줄은 마침표로 끝내지 않는다.
#   Separate subject from body with a blank line
#     본문과 제목에는 빈줄을 넣어서 구분한다.
#   Use the body to explain what and why vs. how
#     본문에는 "어떻게" 보다는 "왜"와 "무엇을" 설명한다.
#   Can use multiple lines with "-" for bullet points in body
#     본문에 목록을 나타낼때는 "-"로 시작한다.
# ------------------

# 으로 시작하는 줄은 주석이며 push시 삭제된다.

2021.07.02 - [Git] Git 관련 설명

[Git] Git 관련 설명

 

ref.

Udacity Nanodegree Style Guide

Git commit message template 만들기

 

How to Write a Git Commit Message

GitHub - spring-projects/spring-framework: Spring Framework

ull.im