최근 프로젝트를 진행하면서 커밋할때마다 메시지 규칙을 정해놓고 사용하고 싶다는 생각은 하곤했다.
읽고 있던 Clean Code 에서도 한번 언급했던 내용이기도 해서
이참에 나만의 커밋 메시지 규칙을 정해두기 위해 한번 검색해봤다.
이미 이 글을 보고 있는 분들은 Commit Message 의 중요한 점은 다들 설명하지 않아도 알거라 생각한다.
프로젝트를 진행하다보면 Git History 를 참고해야할 순간이 온다.
여러 사람들과 협업하다보면 언제 수정된건지, 언제부터 오류가 발생하고 있던 건지 확인하기 위한 필수라고 생각한다.
commit message 고려사항
1. 각각 파일에 무엇이 변경 되었는가? 어떤 클래스가 해당 작업과 관련이 있는가?
2. 해당 코드 수정으로 서비스에 어떤 변화를 일으키는가?
3. 현재 작성하기 간편한 메세지가 아닌, 어떤 commit 이 발생한 건지 내용이 들어가야 한다.
commit message 기본구조
type: Subject
body (changes, links, attributions, etc)
footer / issue tracker id (for reference)
[TYPE]
- feat: 새로 개발된 기능
- fix: 버그 픽스 - 오류 수정
- docs: 주석 혹은 기록 수정
- style: 포맷, 세미콜론 누락 등 코드 변화 없는 경우
- refactor: 운영되고 있는 코드를 리팩토링
- test: 테스트 추가, 테스트 리팩토링 등 운영 소스에는 변화가 없는 경우
- chore: 빌드 옵션, 패키지 config 설정 변경 등 운영 소스에는 변화가 없는 경우
[BODY]
- code에서 변화된 부분에 대한 것을 적는다.
- 추가된 함수에 대한 기능적인 설명이 될 수도 있고, 업무의 온전한 설명이 될 수도 있고, 버그의 발생과 해결에 대한 단계를 작성할 수도 있다.
- 가능한 한 구체적으로 적어라
- 지금부터 몇 년후에 커밋 기록을 다시 읽게 될 수도 있다고 생각하며 미래의 나에게 설명한다고 생각하고 적어라
[FOOTER]
- 선택적으로 작성하며 보통 이슈 트래킹 ID 를 기재한다.
예시
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
좋은 커밋 메시지를 위한 기본 작성 규칙
1. 제목과 본문은 줄 분리하기
2. 제목은 최대한 간결하게
3. 제목 끝에 "." 빼기
4. 제목은 명령문으로 (ex. 수정, 보완 등 )
5. 영문 첫 글자는 대문자로 작성한다.
6. 본문은 How 보다는 What, Why 를 위주로 작성한다.
참고 자료
Udacity Git Commit Message Style Guide
http://udacity.github.io/git-styleguide/
Udacity Nanodegree Style Guide
Introduction This style guide acts as the official guide to follow in your projects. Udacity evaluators will use this guide to grade your projects. There are many opinions on the "ideal" style in the world of development. Therefore, in order to reduce the
udacity.github.io
Git commits: An Effective Style Guide
https://dev.to/pavlosisaris/git-commits-an-effective-style-guide-2kkn
Git commits: An Effective Style Guide
Git commit messaging can either be a pain, or an effective tool. Choose your side!
dev.to
'Etc > 개발 팁 및 기타 정보' 카테고리의 다른 글
[IT용어] IT에서 사용하는 용어 PoC, BMT 뜻 (0) | 2021.10.22 |
---|---|
[TOEFL] 토플 시험 입문, 시험 간단 소개 요약 (0) | 2021.10.14 |
[용어정리] eCommerce에서 사용하는 용어 PLP,PDP, SRP 등 의미 (0) | 2021.07.07 |
Windows 10에서 HEVC 코덱(H.265 비디오용) 오류 해결법 (0) | 2021.04.24 |
보안프로그램에서 개발자도구나 디버그 도구를 탐지하였습니다. 해결(은행 결제 앱 실행시 개발자도구 사용하기) (0) | 2021.04.09 |