GITHUB 협업3 TIPS - Commit Message Convention

https://doublesprogramming.tistory.com/256

Git - 커밋 메시지 컨벤션

쓰다보니 해당 글이 워낙에 잘 쓰이고 압축되어 있어서 거의 copy and paste 수준이 되었다. 

위 글이 더 깔끔하게 잘 정리되어 있으니 해당 글 추천 

---

1. Commit message 구조 

커밋 메시지를 원칙에 따라 일관성 있게 작성해야 팀원 간의 소통이 원할하다. 

 

commit message는 다음과 같이 제목/ 본문/ 꼬리말로 구성된다. 

type: subject

body 

footer

 

2. Commit type 

feat: 새로운 기능 추가 

fix: 버그 수정 

docs: 문서 수정 

style: 코드 포맷팅, 세미콜론 누락, 코드 변경이 없는 경우 

refactor: 코드 리팩토링 

test: test 코드

chore: 잡일 (패키지 매니저, 빌드 업무 수정)

 

3. Subject 

대문자, 마침표 X , 50글자 $\downarrow$

과거 시제 X, 명령어 O 

Fixed X > Fix 

 

4. Body 

모든 커밋에 본문 내용이 필요하지는 않다. 

부연 설명, 커밋 이유 설명이 필요할 때 기재 

72글자  $\downarrow$, 제목과 구분되도록 한칸 띄운다. 

 

5. Footer 

선택 사항

issue tracker id 작성시 사용 

 

6. Example 

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 consequenses 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