개발자는 항상 커밋을 한다.
하지만 항상 어떻게 커밋메세지를 적어야 할지 고민이다.
사람마다 다르겠지만 내가 작성하는 방법의 틀과 생각을 공유해 보고자 한다.

당연하겠지만 개인적인 생각이 다분한 방법이다.

제목

작업내용을 한 줄로 잘 요약해서 제목을 작성하면 된다.
제목은 커밋을 대표하는 내용이니까 최대한 잘 요약해서 만들자.

그리고 제목은 절대 1줄을 넘지 않게 적어야 한다.
2줄이상이면 보기에 좋지 않다.
제목인지 아닌지 알기도 어렵고.

또 길이도 너무 길면 안된다.
개발자 전통을 따라 최대 80자 정도로 제한하는게 좋겠다.
다른 개발자들이 일하는 화면을 보면 의외로 화면을 작게 분할해서 사용하는 분들이 많다.
이럴 때 긴 제목은 보기 안 좋다.

빈줄

제목과 내용 사이에 빈줄을 꼭 넣어줘야 한다.
그래야 git에서 구분을 한다.
빈줄이 없으면 제목이고 내용이고 줄줄이 나오는데
git gui tool이나 oneline으로 보기에 영 안 좋다.

로그를 `--oneline` 옵션으로 보면...

내용

이제 본격적인 내용을 작성하면 된다.
창작의 시간이 되겠다.
적당한 양으로 작업 설명을 하면 된다.

특히 왜 이 작업을 했는지 적어주면 좋다.
단순히 작업내용을 나열하기보다 왜 이 작업을 했는지 적어두면 나중에 커밋을 확인하는 사람이 이해하기가 쉽다.
작업한 내용은 커밋 내용보면 얼추 견적이 나오므로 자세하게 적을 필요는 없다.
간단히 안내만 하자.
diff로 드러나지는 않지만 알리고 싶은 내용이 있으면 적어둔다.

링크

자신의 환경에 따라 연동된 시스템이 있을 수 있다.
이슈 트래킹 시스템 같은?
이런 시스템과 연결하려면 본문 내용 다음에 한 줄 띄우고 링크를 추가하면 커밋에서 시스템으로 간편하게 이동할 수 있다.

커밋할 때 생각할 것들

어디까지 넣을건가?

git은 커밋 단위로 관리한다.
log, merge, cherry-pick 등등... 웬만한 작업은 커밋 단위로 수행한다.
그러므로 커밋은 한가지 목적에 맞게 만드는 게 좋다.
한가지 목적을 수행하기 위한 내용만 들어가는 게 좋다.

이걸 위한 수정도 있고, 저걸 위한 수정도 있고...
이런 커밋은 뭘 했는지도 잘 모르겠고 여러 목적이 섞여서 너무 헷갈린다.
코드 리뷰라도 해야 한다면 리뷰어를 괴롭히는 커밋이 될 것이다.

빌드는 잘 되나?

커밋이 빌드를 깨트리면 안 된다.
어느 커밋에서도 빌드가 잘 되어야 한다.
항상 빌드가 잘 되는지 확인하자.

Worst Case

내가 보기엔 조금 별로 였던 커밋메세지 작성법

한 줄 커밋 (영혼리스 커밋)

가끔은 딱 한 줄로도 충분한 작업이 있긴하다. 한 5%정도?
하지만 나머지 95%는 귀차니즘 때문이라고 생각한다.
당연히 커밋메세지가 별 도움이 되지 못한다.
이런 커밋을 만들고 있다면 동료에게 좋은 평가를 받긴 힘들 것이다.

제목 없는 커밋

이런 커밋은 로그 흐름을 추적한다던지, 머지할 때 좀 거슬린다.

한 바닥 커밋

너무 자세하게 적은 커밋도 있다.
한 바닥을 넘어 스크롤이 필요할 수도 있는데,
중요 기능이 추가됐다면 뭐.. 그럴 수도 있다.
하지만 커밋이 매번 이렇다면 로그 보기가 너무 힘들다.

단순 나열 커밋

보통 “내가 뭐 했음”을 단순히 나열하게 적는 경우가 많다.
나 역시도 무의식적으로 적다보면 이렇게 적을 때도 종종 있다.
이런 내용은 diff에서 대충 다 나오는 내용이다.
간단한 안내면 충분할 것 같다.
그보단 커밋을 보는 사람을 위한 부가적인 정보와 작성자의 생각을 곁들이는게 좋겠다.

이타심

커밋메세지를 작성하다 보면 좀 귀찮기도 하고 이거 누가 보나 싶기도 하다.
확실히 커밋메세지가 근래에 필요해지는 경우는 별로 없긴 하다.

그래도 쌓여가는 커밋 히스토리는 프로젝트의 역사이기도 하고,
내가 만든 커밋을 나중에 누군가가 확인할 일이 생기기도 한다.
그 때 큰 도움이 되는건 잘 만든 커밋메세지다.
그러니 남을 위하는 마음을 가지고 도움이 될 만한 커밋메세지를 적도록 노력해보자.
그리고.. 같은 프로젝트를 하는 사람들은 매번 내 커밋을 지켜보고 있다.