-
[2020.06.13] 더 좋은 커밋 메시지를 남기자개발 블로깅/팀 문화 및 시스템 2020. 6. 13. 14:09
오랜만에 내 github에 있는 옛날 프로젝트 코드들을 살펴보았다.
지금처럼 git에 익숙지 않던 때인지라, commit도 그렇겠지만, 무엇보다 커밋 메시지가 매우 엉망이었다.
내가 남긴 과거의 프로젝트 커밋 메시지... 너무 창피한 이력들..
요즘 드는 생각이 있다면, 영어 메시지로 남긴다면 더 좋기야 하겠지만, 어설픈 영어로 작업한 내용에 대한 설명이 부실해진다면 차라리 한글로 더 명확하게 메시지를 남기는 것이 좋겠다는 생각이다.
트레바리에서 일하면서는 주로 한글로 커밋 메시지를 남기고 있다.
이렇게 메시지 한 줄을 이용해서 과거에 작업했던 내용을 더욱 자세히 알 수 있게 된 것 같다.그런데 문득, 더 좋은 커밋 메시지를 작성할 수 있지 않을까 라는 생각이 들었다. 그래서 인터넷에 찾아보니 좋은 커밋 메시지를 작성하는 방법에 대한 글이 많았고, 이번 기회에 정리하면서 습관을 들여보려고 한다.
좋은 커밋 메시지를 쓰려고 노력해야 하는 이유
우리는 왜 좋은 커밋 메시지를 남겨야 할까. 만약 과거에 작업했던 코드의 이력을 살펴봐야 할 일이 생겼을 때 전체적인 히스토리를 파악하는데 도움이 된다. 그러면 코드에 대해 이해하는데 시간을 많이 단축시킬 수 있다.
- 더 좋은 커밋 로그 가독성
- 더 나은 협업과 리뷰 프로세스
- 더 쉬운 코드 유지보수
하지만 최대한 자세하게 작성한다는 이유로 너무 장황한 커밋 메시지를 남기게 되면, 이마저도 커밋 메시지 파악에 가독성이 떨어지는 요소가 될 수도 있다.
좋은 git 커밋 메시지를 작성하기 위한 간단한 기준
제목
1. 제목과 본문 사이에 한 줄을 띄어 분리한다.
2. 제목의 길이는 최대 40글자까지 간단 명료하게 작성한다.
3. 제목에 .(마침표) 금지
본문
1. 본문의 길이는 한 줄당 60글자 내외에서 줄 바꿈을 한다. 간단 명료하게 작성한다.
2. 어떻게 보다는 무엇을, 왜 변경했는지를 작성한다.# 제목
우선 제목과 본문을 따로 분리하고, 빈 공백 한 줄을 추가하면 상당히 효율적인 메시지가 된다.
제목을 통해 전체적인 작업 내용에 관한 큰 틀을 인지할 수 있고, 본문으로 더욱 정확한 작업 내용을 숙지할 수 있기 때문이다.또한 이러한 방식은 git log 명령어와도 호환이 되기 때문에 테크닉적인 메시지가 될 수도 있다.
git log 명령어
git log : 각 커밋의 메시지 전체 보기.
git log --oneline : 커밋 메시지 한 줄만 보여주기 (제목만 나옴)
git shorlog : Author 별로 묶어서 커밋 메시지를 요약해서 짧게 보여주기제목의 길이는 최대한 40글자 내에 맞추려고 노력해보자. 이 작은 강제성으로 인해, 작성자는 더 간결하고 읽기 좋은 커밋 메시지로 만들 수 있고, 메시지를 읽는 사람도 받아들이기가 더욱 수월해진다. 그러므로 어떻게 하면 작업한 내용을 한 줄 문장으로 표현할 수 있을지 고민하는 습관을 들여보자.
그리고 제목에는 마침표를 찍지 않는 것을 권장하고 있다.
이는 영문 이메일에서 제목에 마침표를 쓰지 않는 것과 유사하다고 한다.# 본문
git에는 자동으로 커밋 메시지 줄 바꿈을 하지 않는다. 그래서 모든 본문 내용이 줄 바꿈이 되어 있지 않고 붙어 있으면, 내용 전환이 되는 부분의 파악이 어렵게 된다. 그러므로 본문의 길이는 한 줄당 60자 내외로 하여 줄 바꿈을 해주면 훨씬 더 직관적인 본문 메시지를 남길 수 있다.
본문 메시지는 '어떻게' 보다는 '무엇을', '왜'에 초점을 맞추어 작성하도록 한다. 작업한 내용을 들여다볼 때에는 가장 중요한 것이 그 상황에 대한 히스토리이다. 어떠한 것에 대해 어떠한 사유로 이렇게 작업을 한 것인지 알아야 해당 작업 사항에 대해 더욱 명확하게 알 수 있게 된다.
또한 '어떻게'에 대한 내용은 제목에서 많이 드러나게 될 것이다.코드도 중요하지만, 앞으론 더 좋은 커밋 메시지를 남길 수 있도록 더 신경쓰고 노력해야겠다.
반응형'개발 블로깅 > 팀 문화 및 시스템' 카테고리의 다른 글
TBD(Trunk Based Development) 전략이란? (0) 2022.06.17 팀워크를 위한 모노레포(Monorepo) 시스템 구축, 그리고 회고 (0) 2022.05.30 [애자일] 함께 자라기-자기계발은 복리로 돌아온다 (0) 2022.05.29 모노레포 환경을 더욱 가볍게 - git sparse checkout (0) 2022.05.28 [Github] Code Owner로 Auto Assign 하기 (2) 2022.03.29