소프트웨어 프로젝트를 진행하면서 다른 개발자와의 협업은 매우 중요하다. 깃허브, 슬랙 등의 협업 도구가 많이 있지만 가장 본질적인 협업 도구는 소스코드이며, 그 중에서도 '커밋 로그'는 다른 개발자와의 소통에서 가장 중요한 수단이다.
소스코드의 수정, 즉 소스코드의 Diff는 무엇이 바뀌었는지를 말하고 커밋 메시지는 왜 바뀌었는지를 설명한다. (소스코드의 Diff는 What, 커밋 메시지는 Why를 말한다.) 따라서 깔끔한 소스코드를 작성하는 것만큼이나 제대로 된 커밋 로그를 작성하는 것도 매우 중요하다.
소스코드를 보면 좋은 개발자인지를 알 수 있고, 커밋 로그를 보면 좋은 협업자인지 알 수 있다. 소스코드는 고쳐 쓸 수 있지만 커밋 메시지는 영원하다. 따라서 좋은 커밋 메시지를 작성하는게 개발자에게는 깔끔한 소스코드를 작성하는 것 만큼이나 중요하다고 할 수 있다.
Git 커밋 메시지를 위한 7대 법칙
좋은 커밋 메시지는 어떻게 작성해야 하는가. 회사 내부 게시판에서 좋은 커밋 메시지에 대한 게시물을 보게 되었다. 많은 사우분들이 댓글을 달면서 좋은 커밋 메시지에 대해서 자신들이 따르고 있는 원칙들을 공유해주었다.
그 중에서 'How to Write a Git Commit Message'라는 게시글의 링크를 보게 되었다. 단순히 '어떻게 커밋 메시지를 써야한다'는 두루뭉술한 내용이 아니라 따라할 수 있는 행동에 대한 내용이어서 읽고 정리해봤다. (링크 : How to Write a Git commit Message)
Git 커밋 메시지를 위한 7대 법칙
- 제목과 내용은 한줄의 빈칸으로 분리하라
- 제목은 50글자 이내로 작성하라
- 제목은 대문자로 시작하라
- 제목을 마침표로 끝내지마라
- 제목은 명령조를 사용하라
- 바디(Body)는 72글자로 래핑(Wrapping)하라
- 바디에 무엇을 왜 바꾸었는지 설명하라. 어떻게 바꾸었는지는 설명하지 않아도 된다.
7개의 내용을 하나하나 요약해보자.
1. 제목과 내용은 한줄의 빈칸으로 분리하라
리팩토링이나 오타 수정 같은 같단한 코드 변경은 제목만 있어도 된다. 하지만 좀 더 설명이 필요한 수정의 경우는 따로 커밋 로그 바디(Body)를 작성할 필요가 있을 수 있다.
이 경우 제목과 바디 사이를 한줄의 빈칸으로 분리해주는 것이 흔하게 통용되는 컨벤션(Convention)이다. 커밋 로그를 화면에 보여주는 다양한 툴들이 제목과 바디 사이의 빈칸을 요구하고 있다. 한줄의 빈칸이 없으면 그런 툴들이 제대로 동작하지 않을 수 있다.
2. 제목은 50글자 이내로 작성하라
반드시 지킬 필요는 없지만 가독성 측면에서 적당한 길이다. 제목을 적을 때 길이 제한이 있으면 커밋 로그에 대해서 '생각'을 하게 되고, 어떻게 하면 간략하고 함축적으로 설명할지 고민하게 만든다. 쓸데 없이 긴 제목보다는 간결하고 함축적이며 수정 내용을 대표할 수 있는 제목을 만들어 내게 된다. (커밋에 대한 자세한 내용들은 커밋 바디에 적으면 된다)
특히 깃허브 같은 UI 도구에서 72글자 이후 제목은 Truncate 시키기도 한다.
3. 제목은 대문자로 시작하라
한국어로 된 커밋 메시지에는 해당하지 않지만 영어로 커밋 메시지를 적을 때에는 대문자로 시작해야하는 컨벤션이 있다. 영어 문장의 시작이 대문자이기 때문에 가독성을 향상시키기 위한 내용으로 생각하면 된다.
4. 제목을 마침표로 끝내지마라
제목의 끝에는 마침표를 찍지 않아야 한다. 50글자 제한에서 1글자는 매우 소중하다.
5. 제목은 명령조로 써라
명령조의 어투에 익숙하지 않을 수 있다. 하지만 간결하게 메시지를 전달하는데 명령조의 어투가 좋다. 특히 깃 자체도 다양한 안내 메시지를 명령조로 작성하고 있다.
명령조가 익숙하지 않다면, 제목 앞에 "If applied, this commit will"을 붙여서 말이 되면 좋은 제목이라고 할 수 있다. 제목은 명령조로 말을 하고, 커밋로그 바디에는 좀 더 부드러운 어투를 사용해도 된다.
6. 바디(Body)는 72글자로 래핑(Wrapping)하라
vi를 이용하여 개발 해본 개발자라면 80글자 래핑(Wrapping)은 익숙한 컨벤션이다.
깃의 경우 커밋 메시지를 출력할 때 인덴트를 추가하는 경우가 있다. 따라서 두 개의 소프트 탭 정도의 여유를 남겨 놓고 커밋로그 바디를 작성하는게 컨벤션으로 자리잡았다.
7. 바디에 무엇을 왜 바꾸었는지 설명하라
커밋 로그의 제목은 간결하게 무엇이 바뀌었는지를 설명한다면 바디에는 무엇을 왜 바꾸었는지를 설명해야 한다. 주의해야 할 점은 "어떻게" 바뀌었는지는 커밋 로그에 기술하지 않아도 된다는 점이다. 어떻게 바뀌었는지는 git diff 등을 통해 직접 확인하면 된다.
커밋 로그의 바디에는 왜 이 수정을 하게 되었는지를 설명해야 한다. 즉, 이전 소스코드에는 무슨 문제점이 있었고 이 부분을 고친 후 왜 제대로 동작하는지, 다른 대안들 중에 왜 이 방법을 선택하게 되었는지를 설명해야 한다.
댓글