Git Commit Message 코드 컨벤션 커밋 규칙
5,310 0
지난달 회사에 한 프런트엔드 전문가가 합류하여 우리 팀을 위한 몇 가지 기술 규칙을 정해 주었습니다. 그중 하나가 Git에 코드를 커밋할 때 Commit Message를 작성하는 규칙에 관한 것이었습니다. 처음에는 저도 불필요하다고 생각했지만, 여러 대형 프로젝트의 Commit 기록을 살펴본 후에야 이 규칙이 업계 표준에 해당한다는 것을 알게 되었습니다.
먼저 제 CodeStudy 프로젝트에서는 어떤 Commit Message를 작성했는지 살펴보겠습니다.
이번에는 우위시 대가의 작품인 Vue 프레임워크의 Commit Message를 살펴보겠습니다.
역시 규칙에 맞는 Commit Message는 정말 사람의 눈길을 사로잡고, 해당 Commit의 내용과 관련 기능 모듈을 빠르게 파악할 수 있게 해 줍니다. 이제 규격화된 Commit Message가 어떤 이점을 가져오는지 이야기해 보겠습니다.
규격화의 이점
- 프로그래머가 커밋 기록을 추적하여 어떤 일이 발생했는지 파악하기 쉽습니다.
Commit Message에 제약을 두면 매번 신중하게 커밋하게 됩니다. 더 이상 여러 가지 변경 사항을 하나의git commit에 무작정 담을 수 없으므로, 전체 코드 변경 이력도 더욱 명확해집니다.- 형식화된
Commit Message만 자동으로Change log를 출력하는 데 사용할 수 있습니다.
Git 커밋 규칙
Plain Text Plain Text
<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 플러그인을 강력히 추천합니다.
댓글
(0)아직 댓글이 없습니다