생각보다 중요한 커밋 메시지

개발을 하다 보면 자주 하루에도 몇 번씩 작성하게 되는 것이 커밋 메시지다. 메세지를 작성할 때 마다 코드 변경사항을 잘 요약해야겠다는 막연한 생각을 하게 되지만, 요약하는 것이 쉬운것이 아니기에 애매한 메시지를 작성하기 쉬운 것이 사실이다.

사실 커밋 메세지는 작업하는 그 당시보다, 나중에 코드를 다시 살펴볼 때 더 중요한 역할을 한다. 내가 작업했지만 무척 오래전 일이라 기억이 안나는 코드를 보거나 혹은 다른 팀원이 작성했던 코드를 리뷰할 때 커밋 메시지는 큰 도움이 된다.

결국 커밋 메시지를 잘 작성한다는 것은 장기적 관점에서 팀의 생산성을 높이고 디버깅할 때 많은 도움을 주는 일종의 보험이라 볼 수 있는데... 문제는 커밋 메세지가 어떠한 제약사항이나 틀이 없기 때문에, 일관되면서도 명확한 커밋 메시지를 작성하는 것이 컨벤션 없이 변수명을 작명해보려는 것과 마찬가지로 쉽지 않다는 것이다.

Conventional Commits

그러던 중 Conventional Commits을 발견하게 되었는데, 커밋 규칙을 보니 코드 변경사항에 대해서 미리 정의된 몇 가지 유형 중 하나를 선택하고, 범위와 주제를 기술하는 걸 골자로 한다.

무척 간단한 규칙이지만 커밋 메시지를 보다 더 일관되게 작성할 수 있고, 표준화할 수 있다는 장점이 그려졌다. 게다가 Semantic Versioning과도 연계가 된다니 생산성 면에서도 무척 유용할 거라 생각되었다.

기본 규칙은 아래와 같다.

기본 규칙

1. 형식: type(scope): subject 형식을 따릅니다.

   • type: 변경의 유형 (예: feat, fix, docs, style, refactor, test 등).
   • scope (선택): 변경이 적용된 범위나 모듈.
   • subject: 변경 내용을 간결하게 설명.

2. 본문: 필요할 경우 변경 사항에 대한 추가 설명 작성이 가능합니다.

3. 예시:

feat(auth): add user login functionality
fix(api): resolve null pointer exception in fetch method
docs: update readme with installation instructions

위 규칙들은 Semantic Versioning과는 아래와 같이 약속된다.

프로젝트가 Semantic Versioning을 적용하고 있다면, 커밋 메시지만으로도 자동으로 버전 관리를 할 수 있습니다. 예를 들어:

• feat(auth): add user login functionality → 새로운 기능 추가 👉 v1.1.0
• fix(api): resolve null pointer exception → 버그 수정 👉 v1.1.1
• feat(payment): add credit card support → 또 다른 기능 추가 👉 v1.2.0

정리해보면 Conventional Commits는 아래와 같은 장점들이 있다.

• 일관성 유자: 일관된 커밋 메시지로 커밋을 작성하니 프로젝트 히스토리를 쉽게 파악 할 수 있습니다.
• 자동화 도구 통합: 릴리즈 노트 생성, CI/CD 파이프라인 통합 등 다양한 자동화 도구와 쉽게 연동됩니다.
• 효율적인 코드 리뷰: 변경 의도를 빠르게 이해하고 리뷰 진행이 가능합니다.
• 확장성 향상: 프로젝트가 커져도 일관된 커밋 메시지로 유지보수가 쉬워집니다.

심지어 린트도 존재한다.(commitlint)

commitlint의 주요 기능은 아래와 같다.

1. Conventional Commits 검증: 메시지가 type(scope): subject 형식을 따르는지 확인합니다.
2. 커스터마이징 가능: 팀의 요구에 따라 규칙을 추가하거나 수정할 수 있습니다.
3. CI/CD 통합: commitlint를 파이프라인에 적용해 커밋 검증이 가능합니다.
4. Husky와의 통합: Git hook을 활용해 커밋 메시지를 자동으로 검사합니다.

특별한 사항이 없는 한 프로젝트에 커밋린트를 적용하는 건 무척 간단하고 여러 이점들이 존재하기 때문에, 팀이 Conventional Commits를 적용하는데 공감했다면 커밋린트도 함께 적용하는 걸 추천한다. 구체적인 구현사항은 commitlint 공식 홈페이지를 참고하자.

이러한 린트가 없이도 개개인이 커밋메세지를 잘 작성할 수도 있겠지만 사람은 여러 이유들로 인해 실수를 할 수도 있고, 실수들로 만들어진 커밋들이 하나둘씩 추가되면 결국 시간이 지나 이도저도 아닌 무언가가 되어있기 마련이다.

게다가 약속을 했는데 커밋메세지가 이상하다고 팀원들에게 피드백을 보내는 것보다는 커밋을 막은 컴퓨터에게 불평하는 것이 협업면에서 백배는 더 효율적이라고 생각한다.

일관된 커밋 메시지, 팀 생산성을 높이는 첫걸음

커밋 메시지는 단순한 변경 기록이 아니라, 프로젝트 히스토리를 정리하고 팀원 간 원활한 협업을 돕는 중요한 도구다. 특히 여러 개발자가 함께 작업할 때, 일관된 커밋 메시지는 코드 리뷰를 수월하게 하고 변경 사항을 쉽게 파악할 수 있도록 한다.

개인 차원에서도 일정한 규칙을 적용하면 불필요한 고민을 줄이고 명확한 메시지를 작성할 수 있으며, commitlint 같은 도구를 활용하면 자동으로 메시지를 검증해 실수를 방지하고, CI/CD와의 연계도 원활해진다.

커밋에도 일정한 규칙을 적용해 일관된 메시지를 작성하는 작은 습관을 들이면 어떨까? 당장은 불편할 수 있지만, 시간이 지날수록 팀 생산성을 높이는 데 큰 도움이 될 것이다.