커밋 메시지 잘 적기
졸업하고 엔지니어의 삶을 산지 벌써 1년이 넘었다. 내가 맡은 프로젝트 뿐만 아니라 다른 프로젝트 개발에도 참여하다보니 자연스럽게 커밋 메시지를 주의깊게 읽고 있는데, 이와 관련해서 어떻게 하면 더 좋은 메시지를 작성할지 고민하던 차에 Peter Hutterer 님의 글 과 Chris 님의 글 을 보고 몇 자 남겨본다.
Git은 상태가 변하는 내용물의 추이를 관리하는 최고의 도구 중 하나다. 어떤 시점의 상태를 커밋이라는 스냅샷으로 남기고 이 커밋들의 트리로 전체적인 흐름을 관리한다는 멘탈 모델은 비단 소프트웨어 개발 뿐만 아니라 다른 분야에도 크게 도움이 된다.
모든 소프트웨어 프로젝트는 협업이 기본일 수 밖에 없다. 혼자 개발하는 개인 프로젝트마저도, 오늘의 나와 몇 달 후의 나는 (거의) 다른 사람이기 때문에 옛날에 했던 커밋과 관련된 문맥을 잊어버릴 게 분명하다. 그래서 로그를 보다가 “내가 대체 이걸 왜 개발했지?”를 쫓아가 머릿속의 메모리에 그때의 맥락을 올리는데 시간이 꽤 걸린다. 그러므로 다른 사람 뿐만 아니라 미래의 나 자신과도 잘 협업하려면 커밋 메시지를 잘 적어야 한다.
좋은 커밋 메시지는 다음 세 가지 질문에 답해야 한다.
- 왜 필요한가? 버그를 고치든, 기능을 추가하든, 성능을 향상시키든, 뭐든 이유가 있을 것이다.
- 어떻게 이 이슈를 다루는가? 고차원(high-level)에서 어떻게 접근했는지를 알려줘야 한다. 디테일은 코드를 보자.
- 미치는 영향은? 엄청 명백한 것 외에 주의해야 할 점을 알려주자. 벤치마크가 달라진다거나, 사이드 이펙트로 어디에 영향이 갈 수 있다거나, 하는 등.
사실 이건 엄청 고수준의 얘기이고, 커밋 메시지를 위한 이상적이고 엄격한 정의같은 것은 없다고 본다. 그래도 각자 자신 만의 기준이 있는 편이 좋다.
내가 중요하게 생각하는 두 가지 기준은 다음과 같다: (1) 하나의 커밋은 되도록 하나의 논리적인 변경만을 담는게 좋고, (2) 모든 커밋은 그 자체로 재현 가능한게 좋다. 논리적인 변경은 기준만 확실하다면 뭐든 괜찮다고 본다. 스타일 수정이든, 버그 수정이든, 리팩토링이든, 뭐든 간에 커밋에 달린 커밋 메시지 한 줄을 읽고 그 수정에 대해서 대략적인 이해를 할 수 있다면 충분하다. 문장이 여러 개로 쪼개진다면 차라리 그 문장 수 만큼 커밋을 쪼개는게 좋다. 재현 가능성은 더 중요한데, 어떤 커밋이든 그 커밋을 체크아웃 했을 때 빌드가 가능한게 좋다. 특히 커밋 히스토리가 방대한 레거시 시스템에서 재현 가능성의 진가를 겪게 되는 경우가 많은데, 모든 커밋이 하나의 온전한 상태이기 때문에 테스트를 해보거나 git-bisect로 내가 원하는 성질을 log(N) 만에 찾는 것이 가능해진다. 생각의 속도만큼 빠르게 뭔갈 해볼 수 있다.