여러분은 Git을 어떻게 사용하고 계시나요?
commit message는 올바르게 작성하고 계시나요?
저는 Git을 작업 내용을 저장하거나, 기록을 남기는 [혼자만의 저장소] 느낌으로 사용하고 있었습니다.
때문에 commit message 또한 적당히 얼버무려 작성하곤 했죠..
하지만 실제 개발 업무는 대부분이 협업으로 이루어지고, 한 프로젝트를 여러 명이서 관리하게 됩니다.
때문에 협업 환경에서 효과적으로 Git을 사용하려면 Commit message convention을 지켜야 합니다.
이번 포스팅에서는 많은 개발자들이 사용하는 대표적인 구조를 토대로 설명하겠습니다.
1. commit message 기본 구조
기본 구조는 다음과 같습니다.
<type>(scope): <subject>
<공백 라인>
(body)
<공백 라인>
(footer)
< type >
작업 내용을 대표하는 키워드이며 필수사항입니다.
대표적으로 쓰이는 키워드는 다음과 같습니다.
- feat: 기능의 추가, 수정, 삭제
- fix: 버그의 수정
- docs: 문서의 변경
- style: 코드 스타일 변경( 코드 포맷팅, 세미콜론 누락 등 )
- design: UI 디자인 변경(css 수정 등)
- test: 테스트 코드에 대한 변경( production 코드 변경 X )
- refactor: 코드 리팩토링( production 코드 변경 O )
- bulid: 빌드 관련 파일 수정
- ci: CI 설정 파일 수정
- chore: 패키지 매니저 설정 변경과 같은 자잘한 수정
- rename: 파일, 폴더명의 수정
- remove: 파일을 삭제한 경우
(scope)
변경이 일어난 곳을 직접 표기하는 곳이며 선택사항입니다.
환경, 디렉터리 명, 파일명, 변수명, 클래스명 등이 들어갈 수 있습니다.
<subject>
작업 내용에 대한 제목을 표기하는 곳이며 필수사항입니다.
최대 50글자까지 허용하며, 제목의 끝에 마침표를 금지합니다. ( 한글 기준 25자 정도가 적당합니다.)
(body)
작업 내용에 대한 상세한 설명을 표기하는 곳이며 선택사항입니다.
'어떻게'보다는 '무엇을', '왜' 하였는가에 집중해 최대한 자세히 작성합니다.
이전과의 차이를 포함해도 좋습니다.
한 줄에 최대 72자까지 허용합니다. ( 한글 기준 36자 정도가 적당합니다.)
(footer)
관련된 이슈를 표기하는 곳이며 선택사항입니다.
[키워드 #이슈 ID] 의 형태로 표기하면 자동으로 해당 이슈를 종료합니다.
키워드는 다음과 같습니다.
- close: 일반 개발 이슈
- fix: 버그 픽스나 핫 픽스 이슈
- resolve: 문의나 요청 사항에 대응한 이슈
2. convention의 효과
1. 좋은 가독성을 바탕으로 변경 내용을 이해하기 쉽다.
2. 변경 내용을 보다 확실하고 정확하게 전달할 수 있다.
3. 쉬운 이해와 정확한 정보를 바탕으로 빠르게 탐색할 수 있다.
4. 결론적으로 협업 환경에서 좋은 업무 효율을 기대할 수 있다.
3. 어느 쪽을 선택하시겠습니까?
둘 중 어떤 사람과 함께 일하고 싶나요?
좋은 코드를 작성하기 위해 많은 고민과 시간을 투자하는 것 처럼,
좋은 commit message를 작성하기 위해 노력해야겠습니다!
같이 일하고 싶은 사람이 되어봅시다.
'Git' 카테고리의 다른 글
| Git - merge, rebase 개념과 차이 (0) | 2022.11.18 |
|---|