Git - Commit Message Style Guide (1)
✨ 깃 커밋 메세지를 잘 쓰고 싶어!
프로그래밍은 나중에서야 왜 많은 사람들이 그렇게 써왔는지, 혹은 그렇게 조언했는지 알 것 같은 상황이 자주 발생하는 듯 하다. 특히 깃 커밋 메세지가 그렇다.
나는 꽤 오랫동안 type: Subject만 작성하는 깃 커밋 메세지 형식을 선택해왔다.🤔 그 때는 크게 불편함을 느끼지 못했고, 이것 도 충분히 하나의 체계로 생각했기 때문이었다.
그런데 작업하는 양이 많아져가 좀더 체계화된 관리의 필요성을 느껴 깃허브 이슈, PL, Feature별 Branch 관리를 도입하게 되니 깃 커밋 메세지도 어떻게 하면 더 효율적으로 이 이슈나 PL을 관리할 수 있을지 고민하게 되었다.
그러다 보니 다시 옛날로 돌아가 깃허브를 처음 배우면서 많은 영상이나 블로그를 통해 접한 Udacity Git Commit Message Style Guide를 도입하는 것이 어떤가 하는 결론에 도달한 것이다!
👀 Udacity Git Commit Message Style Guide
아마 깃, 깃허브를 공부하는 사람들이라면 한번쯤은 봤을 법 한 템플릿이다.
1
2
3
4
5
type: Subject
body
footer
블로그 글도 이를 기반으로 깃허브 커밋메세지 작성을 설명하는 경우가 꽤 많은데, 사실 이 메세지 스타일에 이름이 있는지는 몰랐다.😅 정확한 이름은 Udacity Git Commit Message Style Guide로, 안내 사이트도 있었다!
Udacity를 검색해보니 미국 영리 교육 기관이라고 하는데, 연관성이 있는지는 모르겠다
그래서 이 안내 사이트를 번역해 정리해보고자 한다.
📌 Udacity Git 커밋 메시지 스타일 가이드
🌟 커밋 메시지
메시지 구조 커밋 메시지는 3가지로 구성된다. 각 구성 요소는 빈 줄로 구분된다. 이때 타이틀은 타입과 제목(Subject)으로 구성된다.
1
2
3
4
5
type: 제목
본문
푸터
🌟 타입 (Type)
타입은 타이틀에 포함되며, 다음 중 하나를 사용한다.
- feat: 새로운 기능
- fix: 버그 수정
- docs: 문서 변경
- style: 코드의 포맷팅 변경 (세미콜론 누락 등); 기능 코드 변경 없음
- refactor: 리팩토링 (기능 변화 없는 코드 개선)
- test: 테스트 추가나 리팩토링; 기능 코드 변경 없음
- chore: 빌드 작업, 패키지 설정 파일 등 수정; 기능 코드 변경 없음
🌟 제목 (Subject)
제목을 지을 때는 다음과 같은 규칙을 지키도록 한다.
- 제목은 50자를 넘지 않도록 작성한다.
- 대문자로 시작한다.
- 마침표(.)로 끝내지 않는다.
- 명령문 형태로 작성한다.
💡 ex) Change (변경하다), Add (추가하다) ❌ Changed, Changes 와 같이 과거형이나 3인칭은 사용하지 않음
🌟 본문 (Body)
본문을 작성할 때는 다음과 같은 규칙을 지키도록 한다.
- 모든 커밋에 본문을 작성할 필요는 없고, 복잡한 커밋에만 작성한다.
- 이때 본문에는 무엇(what)을, 왜(why) 변경했는지 설명하며 어떻게(how)는 코드가 설명하기 때문에 작성하지 않는다.
- 제목과 본문 사이에 반드시 빈 줄이 있어야 한다.
- 각 줄은 72자 이내로 작성합니다.
🌟 푸터 (Footer)
푸터는 선택 사항이며, 이슈 트래커 ID를 참조할 때 사용한다.
📌 커밋 메세지 예시
다음은 커밋 메세지 예시를 영문을 번역하여 작성한 예시이다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
feat: 50자 이내로 변경 요약 작성
필요한 경우, 자세한 설명을 작성한다. 각 줄은 약 72자 정도로
줄바꿈하여 작성한다. 일부 도구의 경우 첫 번째 줄을 커밋의 제목으로,
나머지 텍스트는 본문으로 인식하기도 한다. 제목과 본문 사이에는 본문을
생략하지 않는 한 반드시 빈 줄을 넣어야 한다. 그렇지 않으면
`log`, `shortlog`, `rebase`가 내용을 제대로 인식하지 못할 수 있다.
이 커밋이 해결하려는 문제를 설명한다. 변경 이유에 중점을 두되,
어떻게 변경했는지는 코드가 보여주므로 굳이 설명할 필요가 없다.
이 변경으로 인해 발생할 수 있는 부작용이나 예상치 못한 결과가 있다면,
본문에 설명하는게 좋다.
빈 줄을 기준으로 문단을 나눠 추가 설명을 계속할 수 있다.
- 글머리 기호를 사용할 수 있다.
- 일반적으로 하이픈(-)이나 별표(*)를 사용하며, 앞에 공백 하나를 두고
글머리 사이에도 빈 줄을 넣는 것이 좋다. 다만 스타일은 프로젝트마다 다를 수 있다.
이슈 트래커를 사용한다면, 관련 이슈를 아래에 참고 형식으로 작성한다:
Resolves: #123
See also: #456, #789
📚 마치며
사실 해당 형태는 알고 있었지만 자세한 템플릿 내용까지는 파악하지 않았던지라 해당 템플릿에서는 본문에 어떻게(How)를 작성하지 않는 다는 것을 몰랐었다.🤔 (또 나는 종종 작성했던 것 같기도 하고 (…))
작성 방식 지침을 물론 모두 따를 필요는 없겠지만, 충분히 납득 가능한 내용들은 프로젝트에 적용해보면서 개인적으로 정리가 되면 프로젝트에 적용해보는 것을 건의해볼 수 있지 않을까.
이렇게 조금씩 체계를 잡아가도록 노력해보자.