팀 프로젝트를 할 때 깃 커밋 메시지 컨벤션을 정하고 보면 형식이 항상 비슷했던것 같다. feat: "기능 이름" , design:"버튼 색 변경" 이런 식 말이다. 어디서 시작해서 유행하는 건지 궁금했는데 찾아보니 세계적으로 유명한 온라인 학습 플랫폼인 Udacity였다.
type: Subject
body
footer
-feat :새로운 기능 추가
-fix : 버그 수정
-docs : 문서와 관련하여 수정한 부분이 있을 때 사용한다.
-style : 서식 지정,세미콜론 누락 등 코드 변경 없음
-refactor : 코드의 리팩토링
-test : test 코드 관련
-chore : 빌드 작업 업데이트, 패키지 관리자 구성 등
제목은 50자 이하여야 한다.
-선택 사항이며,커밋에 약간의 설명과 컨텍스트가 필요한 경우에만 사용한다.
-제목과 body사이에 빈줄을 띄우고 각 줄의 길이를 72자 이내로 제한해야 한다.
-어떻게 했는지가 아닌, 무엇을, 왜 변경했는지 서술한다.
선택 사항이며, 이슈 id tracker 참조에 사용
feat: Summarize changes in around 50 characters or less
More detailed explanatory text, if necessary. Wrap it to about 72
characters or so. In some contexts, the first line is treated as the
subject of the commit and the rest of the text as the body. The
blank line separating the summary from the body is critical (unless
you omit the body entirely); various tools like `log`, `shortlog`
and `rebase` can get confused if you run the two together.
Explain the problem that this commit is solving. Focus on why you
are making this change as opposed to how (the code explains that).
Are there side effects or other unintuitive consequences of this
change? Here's the place to explain them.
Further paragraphs come after blank lines.
- Bullet points are okay, too
- Typically a hyphen or asterisk is used for the bullet, preceded
by a single space, with blank lines in between, but conventions
vary here
If you use an issue tracker, put references to them at the bottom,
like this:
Resolves: #123
See also: #456, #789