<Git> 커밋 메시지 컨벤션 : 중요성 및 규칙 (feat. 템플릿)

 

1. 커밋 메시지

* 중요성

 - 다음은 자바 스프링의 오래된 커밋 로그이다.

 

$ 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

 

 - 정해진 규칙없이 가독성도 떨어질 뿐만아니라 말하고자 하는바를 정확이 이해하기 힘들다.

 

 - 2014년의 커밋을 보면 다음과 같다.

 

$ 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

 

 - 누가봐도 아래 쪽이 읽기가 편하다. 아래 쪽은 간결하고 일관성이 있다.

 

 - 좋은 커밋 메시지는 동료 개발자 또는 미래의 자신에게 변경사항을 전달하는 데 도움이 될 수 있다.

 

 - 깃 자체에서 무엇이 변경되었는지 알려주지만, 제대로된 이유는 커밋 메시지만이 알려줄 수 있다.

 

 - 간결하고 읽기 쉬운 메시지는 읽는이로 하여금 많은 정보를 빠르게 획득하도록 도울 수 있다.

 

 - 따라서 좋은 커밋메시지는 깃을 사용하는 개발자에게 매우 중요한 일이다.

 

 

* 규칙

 - 대부분의 프로그래밍 언어에는 관용적인 스타일과 같은 잘 정해진 규칙이 있다. 커밋 로그에 대한 팀의 접근 방식도 마찬가지여야 한다.

 

 - 참고로 아래 내용들은 정해진 규칙이 아니므로 반드시 따르지 않아도 좋다. 그러나 대부분의 개발자들이 따르는 컨벤션(관습)이므로 참고한다면 분명 좋은 커밋 메시지를 작성할 수 있을 것이다. 

 

 - 커밋 메시지는 아래와 같은 구조로 이루어진다.

 

제목

본문

푸터

 

 ∙ 각 사항은 공백의 라인으로 구분한다.

 

 ∙ 제목 줄은 가급적 50자로 제한하고, 가능한 간결하게 작성한다.

 

 ∙ 제목의 시작은 대문자로 작성한다.

 

Fix typo in introduction to user guide

 

 ∙ 제목에 마침표를 사용하지 않는다.

 

∙ 제목은 동사로 시작하여 명령형으로 작성한다. 이렇게 작성함으로써 Git 자체가 사용하는 메시지와 통일될 수 있다. 예를 들어 merge를 했다고 가정하자. 그러면 자동으로 아래와 같은 메시지가 로그에 작성된다.

 

Merge branch 'test'

 

 즉, 위의 규칙대로 작성하면 git에서 자동으로 남기는 메시지와도 통일되어 보다 일관된 로그를 남길 수 있다.

 

∙ 본문은 72자 단위로 줄바꿈을 시행한다.

 

∙ 본문을 통해 무엇을, 왜 등을 설명한다. 생략해도 좋지만 코드 변경의 이유를 명확히 작성할수록 코드를 읽는 이가 감사해할 것이다.

 

 - 필자는 git에서 자동으로 남기는 메시지와도 통일성이 있다는 점에서 위와 같은 컨벤션을 따르기 위해 노력한다. 이 글 이후에 다른 커밋컨벤션을 다룰 예정이지만 아직은 이 방식이 편하다. 아래는 리액트의 최근 커밋로그 중 일부이다.

 

 

 

2. 자주 쓰는 단어

 - 아래에서 쓴 문장들은 정해진 규칙이 아니라 자주 쓰이는 단어와 문장형식을 정리한 것이다. 영문법이라고 봐도 좋다.

* Fix

 - 잘못된 동작을 고칠 때 주로 사용한다.

 

Fix my test
Fix typo in style.css
Fix my test to return undefined
Fix error when using my function

 

 - 단순히 명사만 작성하여 수정했음을 나타낼 수 있다.

 

 - in 을 명시하여 어디를 수정했는지 작성할 수 있다.

 

 - to 또는 for 로 왜 그렇게 수정했는지 작성할 수 있다.

 

 - when을 통해 어느 상황에서 발생했는지를 작성할 수 있다.

* Add

 - Fix와 함께 가장 많이 쓰이는 단어이다. 무언가 추가할 때 사용한다.

 

Add style.css
Add mytest.test for test
Add blue color to style.css

 

 - 단순히 코드나 문서가 추가되었음을 작성할 수 있다.

 

 - 왜 추가했는지 무엇을 어디에 추가했는지 등을 나타낼 수 있다.

* Remove

 - 삭제가 있을 때 사용한다.

 

Remove test.js
Remove black color from style.css

 

 - from을 적어서 어디에서 삭제했는지 명시할 수 있다.

* Simplify

 

 - 코드를 단순화 했을 때 사용한다.

* Update

 - Fix와 달리 원래 정상적으로 동작했지만 보완하는 개념이다.

 

Update harry-server.js to use HTTPS

 

* Implement

 - 무언가 구현을 달성했을 때 사용한다.

 

 - 큰 단위에 작성하면 좋다.

* Prevent

 - 특정한 동작을 못하게 막을 때 사용한다.

 

Prevent hello handler from saying Hi in hi.js

 

* Move

 - 코드나 파일의 이동에 사용한다.

 

 - Move A to B, Move A into B의 형태로 많이 쓰인다.

* Rename

 - 이름의 변경이 있을 때, Rename A to B의 형태로 많이 쓰인다.

 

3. 템플릿 설정

 - 자주 커밋을 하다보면 비슷한 형식으로 작성하게 된다. 특히 공동으로 작업하는 경우에는 공동의 규칙을 만들어두기 때문에 더더욱 그렇다. 그 때마다 아래와 같이 작성하는 것은 매우 번거롭다.

 

git commit -m "제목

본문

푸터"

 

 - 커밋 메시지 템플릿을 만들어 두면, 커밋할 때마다 자주 사용하는 형식을 바로 적용하여 작성할 수 있다.

 

 - 먼저 .gitmessage.txt 파일을 생성하고, 자신이 원하는 형식으로 작성한다.

 

 - 아래는 필자가 임의로 작성한 예시이다.

 

# Harry's commit message template
# 제목은 대문자로 시작합니다.
# 본문과 푸터는 선택 사항 입니다.
#######제목#######

#######본문#######

#######푸터#######

##################
# Fix : 수정
# Add : 추가
# Remove : 삭제
# Simplify : 단순화
# Update : 보완
# Implement : 구현
# Prevent : 방지
# Move : 이동
# Rename : 이름변경
##################

 

 - # 은 모두 주석이다. push하면 올라가지 않는다.

 

 - 비어 있는 첫 번째 줄에 글을 작성하면 그것이 커밋 메시지 중 제목으로 작성된다.

 

 - 비어 있는 마지막 줄은 푸터가 된다.

 

 - 파일을 작성했으면 저장하고 아래의 명령어를 입력한다.

 

git config --global commit.template <.gitmessage.txt 경로>

 

 - <...> 부분은 통째로 경로를 작성해야한다.

 

 - 이제 git commit 을 입력하면 아래와 같이 템플릿이 자동으로 뜨게 된다.

 

 

 - vi 에디터 명령어로 작성한다.

 

 - 먼저 i를 입력하여 수정모드로 진입하여 필요한 부분을 작성한다.

 

 - 다 작성했으면 esc 를 누르고, :wq 를 입력해 저장하면 commit이 완료된다.

 

 

 

---

참고

 

ull.im

 

How to Write a Git Commit Message

 

Git Commit Message Conventions

 

Spring

 

GitHub - facebook/react: A declarative, efficient, and flexible JavaScript library for building user interfaces.

 

[GitHub] git commit 템플릿 사용하여 commit message convention 준수하기