얼마전 visual studio에서 깃 사용에 관한 구글링을 하다가 우연치않게 깃 commit message convention에 관한 글을 보게 되었다. 결론부터 이야기하면 git commit message는 팀원들끼리 중요한 약속이기 때문에 반드시 규칙에 맞게 작성해야 한다고 한다. 어떤 회사 채용 담당자분은 "깃 커밋 메세지만 봐도 이 사람을 채용해야 될지 아닐지 판단할 수 있다" 라고 하니 내가 생각했던 것 보다 훨씬 중요한 것 같다. 사실 나는 학부생때까지만 해도 commit message라고 해봤자 "initial commit"이나 그날 날짜와 대강 고친 내용만 쓰는게 전부였다...
그렇다면 이제 git commit message에도 규칙이 있다는 것을 알았으니 그 규칙이 어떤 규칙인지 알아보기 전에 개발자들은 어떤식으로 실제로 git message를 작성하는지 한번 보자.
콜론 뒤에는 뭔가 고친 내용을 쓰는 것 같고, #은 bug같은 issue를 참고하도록 적은듯 하다. 실제 rule을 찾아보면 다음과 같다.
<type>(<scope>): <subject> -- 제목
<BLANK LINE>
<body> -- 본문
<BLANK LINE>
<footer> -- 바닥글
위에서 말하는 타입은 아래와 같은 타입이 있다.
- feat : 새로운 기능 추가
- fix : 버그 수정
- docs : 문서 수정
- style : 코드 formatting, 세미콜론(;) 누락, 코드 변경이 없는 경우
- refactor : 코드 리팩토링
- test : 테스트 코드, 리팽토링 테스트 코드 추가
- chore : 빌드 업무 수정, 패키지 매니저 수정
리팩토링이란 말을 몰라서 찾아보니 생각보다 많은 의미를 담고 있고 중요한 단어여서 따로 공부해서 포스팅했다. 그냥 아주 간단하게만 설명하면 가독성을 높히고 유지 보수 그리고 버그를 찾는데 용이하게 하기 위해서, 외부에서 보이는 동작의 변화없이 내부 동작만 변하게 하도록 코드를 수정하는 것을 의미한다. 예를 들어서 변수명을 남들이 알아보지 못하게 만든게 있으면 쉽게 알아보도록 바꾼다던가, 필요 이상으로 중복되는 동작이 있다면 필요 없는 부분은 지우는 것들이 있다.
다시 commit message rule로 돌아와서, 위의 commit message 제목, 본문 그리고 바닥글에는 각각의 규칙이 있다.우선 제목 작성에는 다음과 같은 규칙이 있다.
1. 제목은 50자를 넘기지 않고, 마침표를 붙이지 않는다.
2. 제목에는 위 커밋 종류를 함께 쓴다(위의 fix, docs 같은 것들)
3. 과거시제를 사용하지 않고 명령조로 작성한다.
4. 제목과 본문은 한 줄 띄워 분리한다.
5. 제목의 첫 글자는 반드시 대문자로 쓴다.
6. 제목이나 본문에 이슈 번호(가 있다면) 붙여야 한다.
그리고 본문은 필수적인 요소는 아니지만 쓰게 된다면 지켜야 할 규칙이 있다.
1. 선택사항이기에 모든 커밋에 본문 내용을 작성할 필요는 없다.
2. 한 줄에 72자를 넘기면 안된다.
3. 어떻게(How)보다 무엇을, 왜(What, Why)에 맞춰 작성한다.
4. 설명뿐만 아니라, 커밋의 이유를 작성할 때에도 쓴다.
마지막으로 바닥글도 필수사항이 아니지만 쓰게 된다면 Issue tracker를 써주는게 좋다
Issue tracker는 위의 angular commit message에서도 볼 수 있는 다음과 같은 것들이다.
Resolves: #123
See also: #456, #789
Reference
https://underflow101.tistory.com/31
'공부 > Git' 카테고리의 다른 글
vi 에디터로 commit message 쉽게 여러줄 작성하기 (0) | 2021.07.18 |
---|---|
Visual Studio 2019에서 git 사용 방법 (0) | 2021.07.16 |