그렇지 않아도 복잡한 Git
, 왜 가이드를 지키며 작성해야 하는것일까?
그냥 편하게 내 맘대로 작성하면 안될까?
정답은 ❌
우리가 Git을 쓰는 이유는 바로 여러 사람과 작업을 하면서 작업의 진행상황을 쉽게 파악하기 위함이다.
심지어 혼자 작업함에 있어서도 어떠한 변경사항이 있었는지 파악하기 위함이다.
바로git message
을 보고 직관적으로 판단할 수 있다.
그래서 우리는 직관적이며 일관성있는 약속을 바탕으로 message 작성을 해야한다.
good message style guide === ! 구성원간의 불필요한 의사소통
딱히 정답은 없다. 통일된 원칙을 바탕으로 일관성이 있으면 된다.
스타일에는 여러 종류가 있지만, 현재 Udacity Style이 가장 널리 쓰이는 방식이다.
(Udacity Style 바탕으로 스타일 가이드를 소개하겠다.)
크게 세 부분으로 나뉘어 진다.
type(scope(선택)) : Subject -- Header(필수)
body -- (선택)
footer -- (선택)
각 부분은 한 줄의 공백으로 구분한다.
tip) git log 사용시 git log --oneline 입력하면 message의 header 부분만 깔끔하게 나온다!
Type은 항상 영문 소문자로 작성
feat
: 새로운 기능을 추가하거나, 기존 기능을 요구사항 변경으로 인해 변경한 경우fix
: 버그를 수정한 경우docs
: 문서(주석) 추가/수정의 경우, 직접적인 코드의 변화 없이 문서만 추가 수정 했을 때style
: UI를 추가/수정하거나, 스타일 관련 작업의 경우refactor
: 기능의 변경 없이, 코드를 리팩토링 한 경우test
: 테스트 코드를 추가/수정한 경우chore
: 기능/테스트, 문서, 스타일, 리팩토링 외에 배포, 빌드와 같이 프로젝트의 기타 작업들에 대해 추가/수정한 경우생략 가능
Header로 표현가능하다면 생략가능한 부분이다
제목에서 하지 못한 커밋의 상세 내역을 작성한다
what
과 why
를 설명생략가능
어떤 이슈에서 왔는지에 대한 참조정보들을 추가하는 용도
(#issueNumber)
cf)한개의 issue에 해당할 시 Header 부분에 작성
ex) Type(scope): Subject(#issueNumber)
그 외에는 footer
에 이슈 번호와 라벨을 추가한다.
여기서 라벨의 종류에는
Resolve
,closes
,Fixes
,see also
가 있는데,
github의 경우 라벨의 종류에 따라 이슈를 닫을 수 있다.