commit message란?
작업중인 로컬 디렉토리
에서 git add
를 하게되면 변경된 파일의 목록이 stage에 추가되는데, 이 파일의 목록들을 HEAD에 반영시킬 때 git commit을 쓰게 됩니다.
commit message는 HEAD에 어떤 변화가 반영이 되었는지 설명하기 위한 글입니다.
규칙에 맞는 좋은 커밋 메세지를 작성해야하는 이유는?
- 팀원과의 소통
- 미래의 나를 위해 편리하게 기록을 추적할 수 있도록 ..💛
커밋 메시지의 7가지 규칙
- 제목과 본문을 빈 행으로 구분합니다.
- 제목을 50글자 내로 제한합니다.
- 제목 첫 글자는 대문자로 작성합니다.
- 제목 끝에 마침표를 넣지 않습니다.
- 제목은 명령문으로 사용하며 과거형을 사용하지 않습니다.
- 본문의 각 행은 72글자 내로 제한합니다.
- 어떻게 보다는 무엇과 왜를 설명합니다.
커밋 메시지 구조
헤더는 필수이며, 범위(scope), 본문(body), 바닥글(footer)은 선택사항입니다.
<type>: <subject> // 헤더
<BLANK LINE>
<body> // 본문
<BLANK LINE>
<footer> // 바닥글
type
해당 커밋의 성격을 나타내며 아래 중 하나를 사용합니다.
feat : 새로운 기능에 대한 커밋
fix : 버그 수정에 대한 커밋
build : 빌드 관련 파일 수정에 대한 커밋
chore : 그 외 자잘한 수정에 대한 커밋
ci : CI관련 설정 수정에 대한 커밋
docs : 문서 수정에 대한 커밋
style : 코드 스타일 혹은 포맷 등에 관한 커밋
refactor : 코드 리팩토링에 대한 커밋
test : 테스트 코드 수정에 대한 커밋
tmi)
사실 test, ci는 써본 적이 없는데욧 ,,
ci는 최근에 프로젝트에 적용해보려다가 잠시 멈춘 상태이구 ...
test는 한 번도 안써본 것에 대해 반성을 해야할 것 같습니다 ^-^
그래도 최근데 test하는 방법을 깨달아서 ...
(또 tmi인데.. 면접 때 라이브코딩하면서 python assertion 처음 써봤습니다 ^-^v)
이번에는 꼭 test 커밋 메시지를 남길 수 있도록 test 코드도 추가해보자 ...~!
여튼 저는 feat
, fix
, build
, chore
, docs
, style
, refactor
을 썼습니다
body
본문으로 헤더를 표현할 수 없는 상세한 내용을 적습니다.
사실 제가 본 블로그에는 헤더로 표현이 가능하다면 생략 가능하다고 적혀있찌만,
body도 적는 것이 친절한 커밋 메시지라는 글을 봐서 소스트리를 사용해서 body까지 좀 예쁘게 적어보려고 노력 중입ㄴㅣㄷㅏ ^-^..~!
footer
바닥글로 어떤 이슈에서 왔는지 같은 참조 정보들을 추가하는 용도로 사용합니다.
예를 들어 특정 이슈를 참조하려면 close #122
와 같이 추가하면 됩니다.
close는 이슈를 참조하면서 main브랜치로 푸시될 때 이슈를 닫게 됩니다.
관련 링크: https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue
tmi) 사실 헤더 말고 안써서 매일 직접 github에서 이슈를 등록해주는데용 .. 이것도 반성하며 바꾸어 보도록 하겠습니다 ^-^v
마치며
사실 이 글을 작성한 이유는 맨날 type찾으러 검색하는 나 자신을 위한 정리 글~~~! 입니다요
[reference]
https://beomseok95.tistory.com/328
https://velog.io/@djh20/Git-%EC%A0%9C%EB%8C%80%EB%A1%9C-%EC%82%AC%EC%9A%A9%ED%95%B4%EB%B3%B4%EC%9E%90
'Study > Git' 카테고리의 다른 글
1일 1커밋 365일 달성 기념 자축 (4) | 2021.12.09 |
---|---|
GitHub commit에 서명하기 (Verified) (0) | 2021.08.29 |
commit (0) | 2021.08.23 |
git init (0) | 2021.08.23 |
Git (0) | 2021.08.23 |