커밋 메시지 컨벤션
posted by mia · 2022-11-13
들어가면서
난 코드리뷰를 좋아하는데, 코드리뷰는 여러가지 이점이 많다고 생각한다. 일단 코드리뷰가 작 동작한다는 전제하에 성장하는데 도움이 되고, 프로젝트에 대한 개발팀 내 공통 이해도가 높아진다. 서로 어느 부분을 건드렸는지 볼 수 있어서 충돌 해결이 좀 더 수월하다. 리뷰를 통해 버그를 더 빨리 발견할 수 있고, 여러 개발자의 리뷰를 통해 소프트웨어 품질이 더 나아질 수 있다고 믿는다. 또 여러 사람이 '리뷰어'로 참여했기 때문에 코드에 대한 책임이 한 개인이 아닌 공동에게 있다는 인식이 만들어져 책임감은 올라가고 부담감은 내리는 좋은 선순환을 만들 수 있다.
하지만, 일정에 쫓겨 개발을 하다 보면 가장 먼저 소홀해 지는 게 코드 리뷰다. 당장 내 작업을 쳐내기도 바빠 죽겠는데 남의 코드를 보고 예상되는 버그를 찾아 멘션을 남기거나 질문을 남기고 더 나은 방식을 제안하는 일이 쉬운 일은 아니다. 시간을 내서 코드리뷰를 하러 갔는데 PR 내용이나 커밋 메시지들을 봤을 때 무슨 내용인지 도통 모르겠고 리뷰에 많은 시간을 쏟아야 될 것 같을 때 무지성 APPROVE를 누르고 싶은 충동에 휩싸이곤 한다. 나 역시도 때때로 '커밋 메시지를 더 자세하게 작성해주세요.'라는 피드백을 받아본 적이 있다. 무지성 APPROVE의 충동과 커밋 메시지 관련 피드백을 줄이기 위해서는 어떻게 하는 게 좋을까? 라는 고민을 하던 중, 커밋 메시지 컨벤션을 만들어 해당 규칙에 기반해 커밋을 한다는 팀을 본 적이 있다.
이건 나한테 제법 획기적으로 다가왔다. 우선 커밋 메시지 형식이 정해져 있으면 리뷰어는 해당 작업이 어떤 성향의 작업인지 한 눈에 알아볼 수 있어서 좋다. 리뷰이는 형식에 맞춰 작업을 묶어야 되기 때문에 커밋 단위를 더 신경쓰고 메시지 역시 더욱 충실히 작성하게 될 것이다.
물론, 좀 불편하기도 하다. 그리고 앞서 말한 건 희망편이라 저대로 동작 안 할 수도 있다. 하지만 중요한 건 이 걸 지키면서 노력하려는 작업자들의 마음... 이라고 생각한다. 코드리뷰는 특히 남을 배려할 때 잘 동작하는 거니까. 그리고 효울을 높이기 위한 시도는 많이 해볼 수록 좋다고 생각한다. 그럼, 서론이 길었으니 커밋 메시지 형식과 내용 작성법에 대해서 간략히 알아보도록 하자.
기본 형식
[commit type]: [commit message]
Commit Type
- feat: 변경사항과 함께 새로운 기능이 추가되었을 때
- fix: 버그 수정이 발생했을 때
- refactor: 버그 수정, 기능 수정 없는 상태의 리팩터링 된 코드
- docs: README 파일 혹은 다른 마크다운 파일과 같은 개발 문서를 업데이트했을 때
- style: 코드의 의미에 영향을 끼치지 않는 변화, 예를 들어 공백이나 세미콜론 등등의 코드 포맷팅
- test: 새로운 테스트 도는 수정된 이전 테스트를 포함시켰을 때
- chore: 그 외 자잘한 변경
- chore 대신 perf, ci, build만 사용하는 경우도 있는 듯(angular 9 규약에서 chore 삭제 됨)
- ex1. 변경사항이 fix 혹은 feature와 관련이 없는 소스(src)나 테스트 파일을 변경하지 않았을 때
- ex2. 패키지 디펜던시 업데이트
- perf: 성능 향상이 포함되었을 때
- ci: CI(배포 자동화) 관련 코드가 수정되었을 때
- build: 빌드 시스템이나 외부 dependency에 영향을 주는 변경사항
- revert: 이전 커밋을 되돌렸을 때
- remove: 필요 없는 기능 or 코드 삭제
커밋 메시지 내용
커밋 메시지의 줄은 100자(영어기준, 한글 기준 약 50자)를 넘기지 않는 게 좋다. 내용은 간결하게 작성하되, 커밋 메시지만 봐도 어떤 작업을 했는지 알 수 있도록 작성한다. 상세한 내용은 PR 본문에 작성해준다.
커밋 메시지 예제
feat: 포스트 상세 화면 구현
style: header 파일 인덴트 수정
fix: 다크모드에서 footer 디자인 깨지는 버그 픽스
refactor: 글 목록 가져오는 로직 리팩터링
...
느낀점
commit type에 맞게 커밋단위를 묶는 게 참 어렵다. 작업한 내용과 type이 딱 맞지 않을 때도 있고, type이 너무 많으니 좀 헷갈릴 때도 있다. 개발한지가 그래도 좀 됐는데도 작업 단위 자르기는 어려운 일이다. 이런 문제들은 계속 써보면서 나한테 잘 맞는 타입들을 추리는 게 좋을 것 같다는 생각이 든다. 커밋 단위 묶는 건 계속 연습을 해야 될 것 같고.
이전 회사에서 프론트 팀내에 커밋 메시지 컨벤션을 도입했을 때도 이런 문제들로 말이 많았는데, 그때도 코드리뷰/PR/커밋메시지 관련 문서를 하나 만들어서 팀원들과 계속 토론해가며 내용을 다듬었었다. 뭐든 현재 자신 혹은 팀의 상황에 맞게 잘 정리하는 게 중요한 것 같다.