#vcs 소스 컨트롤 시스템에서 메시지 내용, 커밋 단위를 이렇게 하는게 좋지 않을까?

업무를 하다가 보면 이런 메시지로 커밋된 것을 발견할 수 있다. 이런 메시지를 보는 즉시 한숨이 나오는건 당연. 가끔 너무 짜증나서 책상을 내려칠때도 있다. 도대체 어떤 버그가 고쳐졌다는 얘긴지 알 수가 없다. 이런 메시지를 적어서 커밋을 한 당사자에게 1달 정도 뒤에 어떤 버그를 고쳤는지 물어보고 싶다. 우리나라에서 서비스 하는 버전에서 특정 버그가 수정되었는데, 이걸 다른 나라에도 적용시키기 위해서 해당 체인지 셋을 찾는데 엄청난 시간을 소비하다가 저런 메시지가 찍힌 체인지셋이 내가 찾던 것이라면 정말 솟아 오르는 짜증을 참기란 어려울 것이다. 버그 수정이라고 메시지를 남겼지만, 내가 생각하기에는 저런 메시지 자체가 버그이다.

대부분의 시스템에서는 메시지를 남기면 손쉽게 수정을 할 수 없다. 그런데 만약 실수로 메시지를 하나도 안 남기고 커밋을 했다면 어떻게 할까? 나는 주로 해당 파일에 스페이스 바를 띄우거나 해서 이전 커밋에 해당하는 메시지를 적고 커밋하는 편이다. 아직까진 더 좋은 방법을 찾지 못해서 이렇게 하고 있다.

이런 메시지 자체로는 아무 문제가 없어 보이나, 만약 저 디버깅 함수를 추가하다가 맘에 안드는 함수 이름이나 변수 이름이 있어서 좀더 깔쌈한 이름으로 변경을 했다고 한다면 저것은 그리 좋은 커밋 단위가 아니다. 디버깅 함수를 추가하면서 어떤 변경점이 있는지 이전 버전과 diff를 떠 본다면 달라진 이름들 때문에 변경점들이 한눈에 들어오지 않을 것이다.

함수나 변수 이름등의 변경을 하나의 체인지 셋 단위로 한다면 특정 기능의 변경점을 확인할때, 달라진 이름들 때문에 변경점 확인이 어려운 상황을 방지할 수 있다. 간간이 이렇게 주석 정리도 한번씩 해주면 좋다.

이렇게 따로 띄어 놓을 수 있는 항목들을 묶어서 커밋하는 것도 변경점 파악을 방해한다. 특히 위와 같은 경우는 하나하나 떼어 놓을 수 있기 때문에 하나하나 떼어서 커밋하는 게 좋다. 물론 모든 경우에 다 이렇게 할 수 있는 건 아니다. 상황에 따라 적절하게 대처하자.

“임무에 실패한 군인은 용서해도 경계에 실패한 군인은 용서하지 못한다.”란 말처럼 버그를 만드는 것은 용서할 수 있어도 성의 없는 커밋 메시지는 용서하지 못하는 것 아닐까?

PS : diff를 안 떠보고 커밋하는 버릇은 정말 반성해야 한다.