깃 커밋 메시지 작성법

본글은 Chris Beams의 How to Write a Git Commit Message을 정리한 글입니다
원문 : https://chris.beams.io/posts/git-commit/

왜 잘 작성된 커밋 메시지가 중요한가

Spring의 초기 커밋 메시지와 최근 커밋 메시지를 보면 그 중요성을 바로 알 수 있다

$ 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 ClassPathXmlApplicationContextTests)
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

커밋 메시지는 미래의 자신은 물론 다른 개발자들에게 변경 사항의 문맥을 소통하는 최고의 방법이다. diff로 뭘 바꿨는지 알 수 있지만, 커밋 메시지만이 왜 바꿨는지 알려줄 수 있다. PR을 리뷰하는게 쉬워지고, 독립적으로도 가능하게 된다. 몇달전, 몇년전에 무엇이 일어났는지 효율적으로 이해하는 것도 가능해진다. 유지보수성이 중요한 현대의 프로그램에 커밋 메시지는 매우 중요하다.

커밋 메시지 스타일은 다양하지만, 모두가 동의하는 점은 모두들 각자 최고라고 생각하는 걸 사용하는것보다 하나를 정해서 모두 따르는게 더 좋다는 것이다. 커밋 메시지 스타일을 정하기 위해 최소 아래 3가지를 정의해야한다.

1. 스타일 : 마크업 신택스, 마진, 문법, 대소문자, 문장부호. 각각 사소해 보일지라도 꼭 명시한다. 이 상황에선 어떻게 해야하는지 고민의 여지가 있어서는 안된다.

2. 컨텐츠 : 커밋 메시지의 본문(작성할 것이라면)에는 어떤 정보가 들어갈지 정한다. 뭐가 들어가면 안될지도 정한다.

3. 메타데이터 : 이슈 관리 ID, PR 번호, 등등 어떻게 참조할것인가?

잘 확립된 컨벤션들이 존재하기 때문에 다행이도 일일히 직접 정할 필요는 없다. 후술할 7가지 규칙을 잘 따르면 된다.

좋은 커밋 메시지를 위한 7가지 규칙

1. 주제와 본문을 빈줄로 구분한다

커밋 메시지 처음에 변경사항을 요약한 문장을 작성한다. 빈줄 하나를 두고 더 상세한 설명을 한다. 빈줄 이전의 문장은 커밋 타이틀로 사용된다.

Derezz the master control program

MCP turned out to be evil and had become intent on world domination.
This commit throws Tron's disc into MCP (causing its deresolution)
and turns it back into a chess game.

git log, git log --oneline, git shortlog로 자연스럽게 제목 본문 처리가 된다

$ git log
commit 42e769bdf4894310333942ffc5a15151222a87be
Author: Kevin Flynn <kevin@flynnsarcade.com>
Date:   Fri Jan 01 00:00:00 1982 -0200

 Derezz the master control program

 MCP turned out to be evil and had become intent on world domination.
 This commit throws Tron's disc into MCP (causing its deresolution)
 and turns it back into a chess game.

$ git log --oneline
42e769 Derezz the master control program

$ git shortlog
Kevin Flynn (1):
      Derezz the master control program

Alan Bradley (1):
      Introduce security program "Tron"

Ed Dillinger (3):
      Rename chess program to "MCP"
      Modify chess program
      Upgrade chess program

Walter Gibbs (1):
      Introduce protoype chess program

2. 주제는 50자로 제한한다

꼭 50자 이내일 필요는 없지만 적절한 글자수이다. 혹시 한글로 작성한다면, 영어보다 적은 문자로 의미를 전달할 수 있으니 30자 정도로 제한하는게 적당할것 같다

팁 : 주제를 요약하는데 어려움을 겪는다면, 한번에 너무 많은 변경사항을 커밋하고 있는건 아닌지 고민해보자

깃허브도 이런 컨벤션을 알고 있어서, 50자를 넘어가면 경고를 표시한다

3. 주제는 대문자화 한다

주제 문장의 첫문자는 대문자로 한다

Capitalize Every First Letter In The Sentence

4. 주제를 마침표로 끝내지 않는다

마침표는 필요하지 않다. 빼자

5. 주제는 명령문으로 작성한다

• Refactor subsystem X for readability

• Update getting started documentation

• Remove deprecated methods

명령조의 문장은 동사 원형으로 시작해서 커밋의 목적을 알아보기 쉽다.

6. 72자에 줄바꿈한다

git은 자동으로 줄바꿈을 해주지 않기 때문에 줄바꿈할 문자수를 정해야한다. 텍스트 에디터를 사용하는게 도움 될 수 있다.

7. 본문을 통해 왜 커밋했는지 설명한다

어떻게 코드를 바꿨는지는 코드의 주석이나 diff로 확인이 가능하기 때문에 메시지에서 표시하지 않는다. 커밋 메시지 본문에서는 무엇을 커밋했고 왜 커밋했는지 설명한다.