느낌 있는 Commit Message 작성하기
Commit Message
커밋(Commit)은 프로젝트 내의 어떠한 파일들에 변화가 있는 시점을 메시지와 함께 저장하는 기능입니다. 커밋 시점은 개발자마다 다릅니다만, 개인적으로는 코드를 기능별(Feature)로 쪼개서 수시로 커밋하는 것을 선호하는 편입니다. 한 번에 여러가지를 해 놓은 이후 커밋하는 것보다, 특정 기능이나 역할 변경에 대해서만 커밋을 남기면, 이후 코드 리뷰가 용이하고 해당 부분만 언급하기도 좋습니다. 만약 너무 많은 커밋으로 인해 로그(Log)가 지저분할 때는 Merge나 Rebase 명령으로로 정리하면 됩니다.
좋은 커밋 메시지
위 사진은 Alibaba Fusion이라는 곳의 저장소에서 가져온 커밋 히스토리입니다. 이 외에도 대형 서비스를 운영하고 있는 기업들의 깃허브에서 커밋 기록을 보면, 대부분 일관되고 직관적인 내용으로 메시지를 작성해 놓은 것을 확인할 수 있습니다. 이처럼 개발은 보통 혼자 하는 것이 아니기 때문에, 좋은 커밋 메시지를 남기는 것이 협업의 효율을 증진시키기 위해서라도 정말 중요합니다. 그렇다면 느낌 있는 커밋 메시지를 작성하기 위해서는 어떻게 해야 할까요?
좋은 커밋 메시지를 작성하기 위한 여러 방법론이 공개되어 있는데, 이들 중 일부를 정리해 봤습니다.
#
# Commit Message 기본 구조
#
<type>(<scope>): <subject>
<blank line>
<body>
<blank line>
(<footer>)[ Subject ] type (커밋 종류)
- feat: 새로운 기능 추가
- fix: 버그 수정
- docs: 문서 수정
- style: 코드 스타일 변경 (코드 포매팅, 세미콜론 누락 등)
- design: 사용자 UI 디자인 변경 (CSS 등)
- test: 테스트 코드, 리팩토링 (Test Code)
- refactor: 리팩토링 (Production Code)
- build: 빌드 파일 수정
- ci: CI 설정 파일 수정
- perf: 성능 개선
- chore: 자잘한 수정이나 빌드 업데이트
- rename: 파일 혹은 폴더명을 수정만 한 경우
- remove: 파일을 삭제만 한 경우
요즘은 정보 압축을 위해 이모지(gitmoji)를 사용하는 커밋 컨벤션도 있습니다.
[ Subject ] scope
- 선택사항이며, 변경된 부분을 직접적으로 표기합니다.
- EX) 함수가 변경되었으면 함수명, 메소드가 추가되었으면 클래스명 기입 등
[ Subject ] subject
- 첫 글자는 대문자로 입력합니다.
- 마지막에는 .(period)을 찍지 않습니다.
- 영문 기준 최대 50자를 넘지 않습니다.
- 제목은 명령문의 형태로 작성합니다. (동사원형 사용)
[ Body ]
- 각 줄은 최대 72자를 넘지 않도록 합니다.
- 어떻게 변경했는지보다, 무엇을 변경했고, 왜 변경했는지를 설명합니다.
[ Footer ]
- 선택사항이며, 관련된 이슈를 언급합니다. Ex) Fixes: #1, #2
- 주로 Closes(종료), Fixes(수정), Resolves(해결), Ref(참고), Related to(관련) 키워드를 사용합니다.
저는 개인 저장소에 커밋할 때는 '[feat] XX 구현', '[fix] XX 수정' 등으로 간단하게 작성합니다.
마무리하며
저는 영어를 잘하는 편이 아니라, 커밋 메시지를 작성할 때 어떻게 작성해야 할 지 항상 고민이 많았습니다. 하지만 커밋 메시지 작성에 대한 여러 방법론을 살펴 보고, 다양한 저장소의 커밋 히스토리들을 보면 엄청 어려운 단어가 사용된 메시지는 많지 않은 것을 알 수 있었습니다. 그래도 Implement, Update, Simplify 등 자주 등장하는 단어들이 있기 때문에, 이런 것들은 미리 알아두고 사용하시면 좋을 것 같습니다.
그래도 영어 공부 열심히 해 두면 좋겠지요 💦
