git 커밋 메시지를 작성하는 방법 (How to Write a Git Commit Message)

아주 유명한 블로거의 글을 참고하였습니다.

chris.beams.io/posts/git-commit/

How to Write a Git Commit Message

왜 좋은 git 커밋 메시지를 작성해야 할까? 😒

git 저장소를 하나 골라서 커밋 로그를 한 번 비교해 보면 이해하기 쉽습니다.

먼저 예-전에 작성된 커밋 로그를 한 번 봅시다.

$ 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

어떤가요? 어떤 로그가 더 이해하기 쉬운가요?

 

처음에 작성된 git 커밋 로그는 메시지 길이도 제각각이고 정해진 규칙도 없는 것처럼 보입니다. 반면에 최근에 작성된 커밋 로그는 꽤 일관된 규칙을 가지는 것 같습니다. 사실 규칙을 정하지 않으면 처음 작성된 커밋 로그처럼 제각각으로 작성하기 쉬운 것이 사실입니다.

 

물론 우리가 새롭게 규칙을 정하는 것도 좋지만, 리눅스 커널이나 Git (진짜 Git 저장소를 개발할 때 그 Git...)에서 남긴 커밋 로그를 보면 우리는 어떠한 일관된 규칙을 찾을 수 있을 것입니다.

 

🤦‍♀️ 여담이긴 하지만 나쁜 커밋 메시지를 보면 왜 커밋 메시지를 잘 써야하는 지 단박에 이해할 수 있다.
내가 실제로 본 끔찍한 커밋 메시지는 다음과 같았다.
$ XXX Update -1
$ XXX Update -2
$ XXX Update -3
변경사항이 무엇인지 전혀 이해할 수 없었고, 나중에 revert가 필요할 때에는 커밋 3개를 모두 revert 해야했다.

 

좋은 git 커밋 메시지를 작성하기 위한 7가지 규칙 📢

1. 제목과 내용사이에 공백을 하나 추가한다

2. 제목의 길이는 50글자를 넘기지 않는다

3. 제목의 첫 글자는 대문자로 작성한다

4. 제목의 마지막에 마침표를 사용하지 않는다

5. 제목은 명령문으로 작성한다 (영어의 명령문)

6. 본문을 작성할 때 72글자를 넘기지 않도록 엔터를 눌러 줄바꿈한다

7. 본문에는 어떻게 보다는 무엇을, 그리고 왜 바꾸었는지 설명한다

 

다음은 좋은 커밋 메시지의 예시입니다.

제목과 내용사이에 공백을 하나 추가하였고, 제목의 길이는 50글자를 넘기지 않았습니다.

그리고 무엇보다도 본문에서 "serialize.h 예외 처리 단순화"에 대해 "무엇을", "왜" 변경했는지 설명하고 있다는 것이 중요합니다.

commit eb0b56b19017ab5c16c745e6da39c53126924ed6
Author: Pieter Wuille <pieter.wuille@gmail.com>
Date:   Fri Aug 1 22:57:55 2014 +0200

   Simplify serialize.h's exception handling

   Remove the 'state' and 'exceptmask' from serialize.h's stream
   implementations, as well as related methods.

   As exceptmask always included 'failbit', and setstate was always
   called with bits = failbit, all it did was immediately raise an
   exception. Get rid of those variables, and replace the setstate
   with direct exception throwing (which also removes some dead
   code).

   As a result, good() is never reached after a failure (there are
   only 2 calls, one of which is in tests), and can just be replaced
   by !eof().

   fail(), clear(n) and exceptions() are just never called. Delete
   them.