[Git] 커밋 (commit) 메세지 잘 쓰는 법 - 1. 커밋 메세지를 잘 작성해야 하는 이유

 프로그래밍 협업에 있어 필수적인 툴인 git. 이를 사용하여 단순히 변경사항만을 push하는 것은 협업의 의미가 없기때문에 보다 효율적인 협업을 위해서는 커밋 메세지를 효과적으로 작성할 필요가 있다.

 이를 위해 git 커밋 메세지 잘 쓰는 방법을 영어로 되어있는 한 포스팅을 보고 추후 참고할 수 있도록 한글로 정리한다. 

 

참조 : https://chris.beams.io/posts/git-commit/

How to Write a Git Commit Message

 

커밋 메세지를 잘 작성해야 하는 이유

 공개되어 있는 임의의 git repository를 보면 커밋 메세지가 엉망인 경우가 많은데, 아래와 같은 커밋 메세지가 있다고 하자.

$ 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

어떤 것이 더 읽기 쉬운가?

 

 위 두 커밋 메세지를 비교해보면 가장 먼저 직관적으로 첫 번째는 메세지 길이가 일관적이지 않고 두 번째는 일관적인것을 확인할 수 있다.

 

 대다수의 repository의 커밋들은 첫 번째인 경우가 많지만, Linux 커널이나 git 자체에서 사용하는 커밋 메세지 작성법이 올바른 경우이며 이러한 커밋 메세지가 협업을 하는 사람에게 어떤 변화가 일어났는지 가장 효과적으로 전달할 수 있는 방법이다. diff만을 보면 코드의 변화만을 알 수 있지만 커밋 메세지를 보면 어떤 이유로 이러한 변화가 일어났는지 알 수 있기 때문이다.

 

 따라서 이러한 커밋 메세지 로그를 잘 관리한 다는 것은 몇개월 전, 몇년 전에 수행했던 작업에 대해 효율적으로 이해할 수 있다. 많은 시간이 지난 프로젝트에 대한 커밋 메세지 로그를 보는 경우는, 경력이 많지 않은 개발자 입장에서는 경험할 일이 없었을 것이다. 하지만 실제 현업에서의 프로젝트는 단순히 개발이 전부가 아니라 유지보수도 포함되는 것이기 때문에 이러한 잘 짜여진 커밋 로그를 쌓는 과정은 유지보수의 관점에서도 매우 중요하다.

 

 협업의 과정에서 모든 프로그래밍 언어에 존재하는 것처럼 커밋 메세지에 대해서도 일종의 규약이 존재해야 하는데 크게 3가지로 나누어서 규약을 정의한다. 이 규약은 협업의 과정에서 규약 내용을 정의하고, 서로 인지하고 동의하는 절차가 필요하다.

 

 먼저 Style. Markup syntex나, 줄바꿈 여백, 문법, 대문자, 특수문자. 이런것들을 통해 가능한 사실만을 기입하며 최대한 단순하게 작성해야 한다. 형식에 맞고 간결하게 작성된 커멧 메세지는 가독성이 향상될 뿐만 아니라 일관성도 향상시킬 수 있다.

 

 두번째로 Content. 커밋 메세지에 어떠한 정보가 들어갈 것인지, 또 어떠한 내용이 들어가면 안되는지에 대한 정의가 필요하다.

 

 마지막으로 Metadata. 이슈 트래킹 ID, pull request number와 같은 내용을 어떻게 참조해야 하는지에 대한 정의가 필요하다.

 

 위 세가지 규약만을 보면 생각보다 뜬구름 잡는 소리인 것처럼 보이고, 정확하게 어떻게 상세한 내용을 정해야하는지 감이 오지 않을 수 있다. 하지만 이미 관용적으로 git 커밋 메세지에 대해 잘 작성하는 법에 대한 관습이 존재하고, git command function에 대해서도 정의하고 있기 때문에 감이 잡히지 않는다면, 새로 만들 필요 없이 기존에 존재하는 방법만 사용해도 잘 짜여진 커밋 메세지를 작성할 수 있다.