좋은 커밋 메시지 생각해보기

이번에 Github에 대해 다시 생각해 보는 기회가 생겼고, 그중에서도 좋은 커밋이란 무엇일까에 대해 고민을 하면서 찾게 된 세 가지를 정리해보려 한다.

1. Atomic Commit

Atomic Commit은 A Developer’s Guide to Atomic Git Commits - Sandro Dzneladze의 글을 바탕으로 정리하려고 한다.

글에서는 커밋을 "더 이상 쪼갤 수 없는, 의미 있는 최소 단위"로 정의한다. 그러기 위해서 다음과 같은 세 가지를 만족해야 한다.

1. 하나의 논리적 변경만 담는다
2. 커밋 이후에도 코드베이스가 동작하는 상태여야 한다
3. 관심사를 섞지 않는다 (ex: feat: xxx기능 변경 및 리팩터링)

이렇게 함으로써 다음과 같은 7가지 이점을 얻을 수 있다.

1. 안전성
   • 커밋이 하나의 관심사를 가지고 있기 때문에 문제가 생겼을 때 revert와 cherry-pick이 쉬워짐
2. 품질
   • 변경이 작고 집중돼 있어 버그가 덜 생김
   • 리뷰와 테스트가 쉬워짐
3. 계획
   • 기능을 잘게 쪼개는 습관이 더 나은 설계로 이어짐
4. 추적성
   • 커밋 메시지를 통해 왜 바꿨는지, 파일의 변경을 통해 무엇을 바꿨는지, 즉 커밋의 의도를 알기 쉬워짐
   • 몇 달 후에도 "왜 이렇게 바꿨는지" 히스토리로 알 수 있음
5. 협업
   • 리뷰어가 작은 단위를 보기 때문에 피드백의 질이 올라감
   • Merge conflits를 해결하기 쉬워짐
6. 디버깅
   • git bisect와 같은 명령어로 버그를 찾는 과정이 Atomic Commit에서 더 빠르고 정확하게 작동함
7. 릴리즈 관리
   • 명확한 commit이 changelog 자동 생성 도구와 잘 맞음

2. 커밋 컨벤션

커밋 컨벤션에 관해서는 관련 글이 많으므로 간단하게만 정리하고 넘어가려고 한다.

여러 컨벤션 중, 많이 알려진 컨벤션으로 Conventional Commits에서 정리된 커밋 컨벤션이 있다.

기본 형태는 다음과 같다.

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

이를 통해 다음과 같은 이점을 얻을 수 있다.

• CHANGELOG를 자동으로 생성하기 위해서
• (포함된 커밋의 타입에 기반하여) 유의적 버전을 자동으로 변경하기 위해서
• 팀 동료, 타인, 그리고 기타 이해당사자에게 변화의 본질을 전달하기 위해서
• 빌드와 배포 프로세스를 수행하기 위해서
• 더 구조화된 커밋 히스토리를 보여줘서 사람들이 프로젝트에 기여하기 더 쉽도록 하기 위해서

3. 커밋을 얼마나 자주 해야할까

사실 Atomic Commit의 개념은 이해하기 어렵지 않다. 다만 실제로 이를 실천하려고 할 때 생각보다 잘 되지 않는 경우가 많았다.

결국 커밋을 Atomic 하게 만들기 위해서는 자주 커밋을 해야한다. 하지만 처음 접하는 도메인을 개발한다든지, 큰 규모의 리팩터링 작업같은 걸 하다 보면 Atomic하게 만들려고 노력해도 어느새 커밋이 돌이키기 힘들 정도로 거대해져 있는 경우가 많았다.

그래서 이에 관한 내용으로 찾아보던 중, 이 주제로 토론하는 글들을 보게 되었다.

https://www.reddit.com/r/webdev/comments/1d2bvri/how_often_to_commit

https://www.reddit.com/r/cscareerquestions/comments/10lrfr9/how_often_should_you_commit_changes

이 글들에서 다음과 같은 의견들을 볼 수 있었다.

개발 중에는 자유롭게 자주 커밋 → PR 올리기 전에 squash로 정리 → PR

일반적으로 작업하고 커밋하면서, 만약 불가피한 경우에 저장 용도로 커밋한 경우 공유하기 전에 히스토리를 다듬는 방식이다.

다만 무분별한 squash는 오히려 개발 과정의 사고 흐름과 맥락을 지워버린다. 기능 단위가 크다면, 의미 있는 중간 커밋들을 억지로 하나로 뭉개면 히스토리가 오히려 불투명해질 수 있다. squash는 의미 없는 커밋을 정리하는 게 목적이지, 단순히 보기 좋게 작게 만드는 작업이 되어서는 안 된다.

정리

개발자의 덕목으로 소통을 꼽는 사람이 많다. 그런데 소통이 꼭 말이나 글로만 이루어지는 건 아니다. 팀에서 일할 때, 우리가 가장 자주 마주치는 "소통의 결과물" 중 하나는 바로 커밋 히스토리다.

잘 작성된 커밋은 리뷰어가 맥락을 파악하는 시간을 줄여주고, 히스토리를 읽는 사람이 의도를 이해할 수 있게 해준다. 반대로 뭉텅이로 올라온 커밋은 상대방에게 "알아서 파악해"라고 말하는 것과 다르지 않다.

당연하다고 생각하면서도 잘 되지 않아 난장판이 된 나의 커밋 기록들을 보면서 반성하고 더 나은 커밋을 작성할 수 있도록 노력해야겠다는 생각을 했다.

 

참고자료

https://medium.com/@sandrodz/a-developers-guide-to-atomic-git-commits-c7b873b39223

A Developer’s Guide to Atomic Git Commits

https://www.conventionalcommits.org/en/v1.0.0/

Conventional Commits

https://www.reddit.com/r/webdev/comments/1d2bvri/how_often_to_commit

Reddit의 webdev 커뮤니티

https://www.reddit.com/r/cscareerquestions/comments/10lrfr9/how_often_should_you_commit_changes/

Reddit의 cscareerquestions 커뮤니티

https://jaeheon.kr/257

커밋을 잘게 쪼개자 - 커밋은 언제 하는 것이 가장 좋을까?