우리는 왜? 좋은 commit message를 써야 할까요?
1. Provide context to the code reviewer: 좋은 커밋 메시지는 코드 검토자가 코드를 자세히 살펴볼 필요 없이 커밋 메시지의 내용만으로 달성한 내용을 제공할 수있습니다. 이를 통해 검토 프로세스의 많은 시간을 절약할 수 있습니다.
2. Help in maintaining a feature log: 개발자는 종종 커밋 메시지의 기록을 살펴보며 마지막 릴리스 이후 추가/제거/수정된 기능에 대한 아이디어를 얻을 수 있습니다.
3. provide knowledge transfer: 대부분의 프로젝트에는 서로 다른 기능에 대해 작업하는 여러 사람/팀이 포함됩니다. 각 엔터티는 일반적으로 로컬 브랜치에서 작동하며, 정기적으로 마스터와 리베이스 합니다. 이러한 경우 적절한 커밋 메시지를 통해 다른 공동 작업자가 구현한 코드 변경 사항에 대한 폭 넓은 아이디어를 가지면 상호 커뮤니케이션에 소요되는 개발자의 시간을 많이 절약할 수 있습니다.
좋은 commit message를 남기는 방법
좋은 커밋 메시지를 작성해야하는 'why'를 보았으니 이제 'How'에 대해 살펴보도록 하겠습니다
- 제목과 본문을 빈 행으로 구분
- 제목은 영문 기준 50글자 이하
- 첫 글자는 대문자로 작성
- 제목 끝에 마침표X
- 제목은 명령문으로 작성(현재 시제)
- 본문의 각 행은 영문 기준 72 글자 이하
- 어떻게 보다는 무엇과 왜
Type
| Type 키워드 | 사용 시점 |
| feat | 새로운 기능 추가 |
| fix | 버그 수정 |
| docs | 문서 수정 |
| style | 코드 스타일 변경 (코드 포매팅, 세미콜론 누락 등) 기능 수정이 없는 경우 |
| design | 사용자 UI 디자인 변경 (CSS 등) |
| test | 테스트 코드, 리팩토링 테스트 코드 추가 |
| refactor | 코드 리팩토링 |
| build | 빌드 파일 수정 |
| ci | CI 설정 파일 수정 |
| perf | 성능 개선 |
| chore | 빌드 업무 수정, 패키지 매니저 수정 (gitignore 수정등) |
| rename | 파일 혹은 폴더명을 수정만 한 경우 |
| remove | 파일을 삭제만 한경우 |
관련 이슈
| 사용 시점 | 사용 키워드 |
| 해결 | Closes(종료), Fixes(수정), Resolves(해결) |
| 참고 | Ref(참고), Related to(관련), See also(참고) |
관련 이슈 언급은 선택사항입니다.
참고
'Git' 카테고리의 다른 글
| [Git] Warning: Permanently added 'github.com' (ECDSA) to the list of known hosts 에러 해결 (0) | 2023.05.25 |
|---|
