지난달 회사에 프런트엔드 고수가 한 분 오셔서 우리 팀의 기술적인 규범을 몇 가지 정해 주셨는데, 그중 하나가 Git에 코드를 제출할 때 Commit Message를 작성하는 규범에 관한 것이었습니다. 처음에는 저도 쓸데없는 일이라고 생각했지만, 여러 대형 프로젝트의 Commit 기록을 살펴본 후에야 이 규범이 업계의 표준에 해당한다는 것을 알게 되었습니다.
먼저 제 CodeStudy 프로젝트에서는 Commit Message를 어떻게 작성했는지 살펴보겠습니다.
이번에는 우위시(尤雨溪) 고수의 작품인 Vue 프레임워크의 Commit Message를 살펴보겠습니다.
역시 규범에 맞는 Commit Message는 정말 사람의 눈을 사로잡고, 해당 Commit의 내용과 관련 기능 모듈을 빠르게 파악할 수 있게 해 줍니다. 이제 규범화된 Commit Message가 어떤 이점을 가져다주는지 이야기해 보겠습니다.
규범화의 이점
- 프로그래머가 제출 기록을 추적하여 어떤 일이 발생했는지 파악하기 편리합니다.
Commit Message를 제약한다는 것은 매번 제출할 때 신중하게 진행한다는 의미입니다. 더 이상 여러 가지 변경 사항을 한꺼번에 하나의git commit에 담을 수 없으므로, 전체 코드 변경 이력도 더욱 명확해집니다.- 형식화된
Commit Message만 자동으로Change log를 출력하는 데 사용할 수 있습니다.
Git 제출 규범
<type>(<scope>): <subject>
<body>
<footer>
| 이름 | 역할 |
|---|---|
| type | Git Commit의 분류를 설명하며, 아래 표의 식별자만 사용할 수 있습니다 |
| scope | 데이터 계층, 제어 계층, 뷰 계층 등 Commit의 영향을 받는 범위를 설명합니다 |
| subject | Commit 목적에 대한 간단한 설명으로, 일반적으로 50자를 넘지 않습니다 |
| body | 생략 가능하며 여러 줄로 작성할 수 있습니다. 자세한 설명을 기재하고 header와 한 줄 띄웁니다 |
| footer | 생략 가능하며 일반적으로 호환되지 않는 업데이트나 issue 종료에 사용하고 body와 한 줄 띄웁니다 |
| 유형 | 설명 |
|---|---|
| sync | 메인 브랜치 또는 브랜치의 bug 동기화 |
| merge | 코드 병합 |
| revert | 이전 버전으로 되돌리기 |
| chore | 빌드 과정 또는 보조 도구의 변경 |
| test | 소프트웨어 테스트 추가 |
| perf | 성능, 사용 경험 향상 등 최적화 관련 |
| refactor | 리팩터링. 새로운 기능 추가도 아니고 bug 수정도 아닌 코드 변경 |
| style | 코드 실행에 영향을 주지 않는 형식 관련 변경 |
| docs | 문서 작성 또는 업데이트 |
| fix / to | bug 수정. QA가 발견한 bug일 수도 있고 개발자가 직접 발견한 bug일 수도 있습니다 |
| feat | 새로운 기능(feature) |
플러그인 추천
VS Code에서는 Git Commit Message를 빠르게 생성할 수 있는 Commit Message Editor 플러그인을 강력히 추천합니다.
