git에 대해 찾아 보다가, Git for the lazy 라는 글을 찾았습니다. url로 봐서는 공부하기 귀찮아 하는 git 초보를 위한 치트시트같은 글입니다. 글 목차만 쭉 훑어보고 북마크해두는 것만으로도 충분히 활용 가치가 있는 내용입니다.
근데 뒤쪽에서 의외의 내용을 발견했습니다. 바로 "좋은 커밋 로그"를 쓰는 방법에 대해서 설명한 부분인데 막번역 해보면 이렇습니다.
이 부분은 필자의 의견이지만, 따라 하면 읽기가 쉬워진다.
첫 줄은 한 문장으로 변경 사항을 요약해서 적는다. 이 문장은 50자 이하의 길이로 하고, 현재형으로 쓴다. (이 부분은 git에 대한 것인데) 이 메세지는 git의 merge 커밋 로그가 되는데, branching, merging 시에도 이 메세지를 보게 될 것이다.
그 아래로는, 필요한 경우 더 자세한 내용을 적는데, 일정한 규칙을 사용한다. 스페이스 한칸, * 표, 또 스페이스 한 칸을 들여쓴 후 필요한 내용을 적는다.
예)
- Add feature X to subsystem Y.
* Feature X isn't working well with feature Z. Worth investigating.
* Feature X still doesn't work for inputs A, B and C.
git으로 여러번 commit을 하고 push 하게 되면, 각 커밋 메세지들이 합쳐져서 한 메세지가 됩니다. 로그를 대강대강 작성하면 이 과정에서 눈에 잘 들어오지 않는 메세지가 되고 결국 커밋로그 자체가 의미가 없어지게 되죠..(비단 git만 해당되는 이야기는 아닙니다. 모든 버전관리 시스템이 마찬가지지요.) 이런 이유 때문에 커밋할 때마다 약간의 노력을 들여서 잘 꾸며 놓으면 항상 유용하고 눈에도 잘 들어오는 좋은 정보가 되겠죠. 좀더 덧붙여서, 버그 관리 시스템에서 제공하는 버그 정보가 담긴 url이나, Trac 의 티켓 번호, 기타 관련 url이 있다면 로그에 같이 남겨 봅시다.
오타 수정이나 아주 단순한 리팩토링의 경우 로그를 안 남기고 커밋하고 싶은 유혹이 생기게 마련인데, 사실 변경(커밋)은 작든 크든 오류를 낼 수 있는 가능성을 가지고 있기 때문에 커밋로그라는 방법을 통해서 기록을 남겨두는 것이 좋을 것 같습니다. 이제 'refactor' 혹은 '오타수정;;;' 등의 로그만 남기고 커밋하는 일을 줄여야 겠습니다 -.-;;
참고 자료
- http://www.spheredev.org/wiki/Git_for_the_lazy#Writing_good_commit_messages
- http://tisphie.net/soojung/entry.php?blogid=122
이 글은 스프링노트에서 작성되었습니다.
