Notice
Recent Posts
Recent Comments
Link
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
26 | 27 | 28 | 29 | 30 | 31 |
Tags
- 코틀린
- Kotlin
- 혼공파
- Android
- 안드로이드스튜디오
- doitandroid
- SQL
- 오블완
- CS
- 코테
- 알고리즘
- MySQL
- join
- 자바
- 정처기
- select
- 티스토리챌린지
- 혼공챌린지
- java
- 정보처리기사
- 기술면접
- Til
- 프로그래머스
- groupby
- 인프런
- 혼공단
- 자료구조
- 안드로이드
- 카카오코테
- 스터디
Archives
- Today
- Total
Welcome! Everything is fine.
[Git] 커밋 메세지 컨벤션(Commit Message Convention) 가이드 본문
728x90
커밋 메시지를 아무렇게나 작성하는 것에서 벗어나 컨벤션에 따라 일관성 있게 작성해 보자!
커밋 메세지 컨벤션에 따라 작성하면 가독성도 좋아지고 협업 시에도 더 도움이 될 것이다.
내용은 아래 커밋 메시지 컨벤션을 번역해 간단하게 정리하였다.
📌 커밋 메세지 형식
커밋메시지는 header, body, footer로 구성되며 빈 줄을 띄워 나눈다. 커밋 메시지는 읽기 쉽게 한 행에 100자를 넘기지 않도록 작성한다.
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
📌 header
- header는 변경사항에 대한 설명을 간결하게 표현해야한다.
- header는 type, scope, subject로 구성된다.
type
type은 변경 사항이 어떤 종류인지 나타내는 단어나 약어를 말한다.
타입 | 설명 |
chore | 빌드 테스크, 패키지 매니저 설정할 때 |
feat | 새로운 기능을 추가했을 때 |
docs | 문서를 수정했을 때 |
refactor | 리팩토링 했을 때 |
test | 테스트를 추가하거나 테스트 리팩토링 했을 때 |
fix | 버그를 고쳤을 때 |
style | 코드 포맷 변경, 세미 콜론 누락, 코드 수정이 없을 때 |
remove | 코드(파일)를 삭제했을 때 |
rename | 파일명을 변경했을 때 |
scope
scope는 변경 사항이 적용되는 범위나 영역을 나타내며, 어떤 것이든 될 수 있다. 예를 들어 $location, $browser, $compile, $rootScope, ngHref, ngClick, ngView, 등과 같이 쓸 수 있다. 사용자는 적합한 scope가 없는 경우 '*'를 사용할 수 있다.(이 부분은 이해가 잘 되지 않아서 chatGPT에게 물어봤더니 다음과 같은 답을 해주었다.)
"*"를 사용하는 것은 "Scope"를 비워두는 것과 유사한 역할을 합니다. 이것은 커밋이 특정 위치나 영역과 관련이 없을 때 사용되며, 이렇게 하면 다른 개발자들이 커밋 메시지를 읽을 때 어떤 "Scope"가 없음을 이해할 수 있게 도와줍니다.
subject
subject에는 변경 사항에 대한 설명을 아주 짧게 적는다. 주의사항은 다음과 같다.
- 명령형, 현재형 시제를 사용한다.("changed"나 "changes"가 아닌 "change")
- 첫 문자를 대문자로 적지 않는다.
- 끝에 온점(.)을 찍지 않는다.
📌 body
- 명령형, 현재형 시제를 사용한다.("changed"나 "changes"가 아닌 "change")
- 해당 변경 사항이 필요한 이유를 설명한다.
- 이전 동작이나 상태와 비교해 무엇이 다른지 설명한다.
📌 footer
Breaking changes
- 모든 "breaking changes"는 커밋 메시지의 "footer" 부분에 "breaking change block"으로 언급되어야 한다.
- "breaking change block"은 "BREAKING CHANGE:"라는 단어로 시작하고, 그 뒤에 한 칸을 띄우거나 또는 두 줄의 공백을 두어야 한다.
- 커밋 메시지의 나머지 부분은 변경 사항의 설명, 정당성, 및 이전 버전에서의 마이그레이션에 대한 노트를 포함해야 한다.
Referencing issues
이미 해결된 버그를 커밋 메시지에 포함하려면 'Closed'라는 키워드를 사용하고 별도의 줄에 명시되어야 한다.
Closes #234
이슈가 많을 경우 다음과 같이 작성한다.
Closes #123, #245, #992
더 자세한 예시는 커밋 메세지 컨벤션링크를 통해 확인할 수 있다. 꼼꼼히 읽어보고 깔끔한 커밋 메시지를 작성할 수 있도록 노력하자!
'TIL' 카테고리의 다른 글
[TIL] 241125 - SQL 공부 / 코테 풀이 (0) | 2024.11.25 |
---|---|
[TIL] 241122 - SQL / Java 공부 (0) | 2024.11.23 |
[Git] 깃 특정 브랜치만 clone하기 (0) | 2022.06.16 |
[TIL] 220306 (0) | 2022.03.06 |
[TIL] 220302 (0) | 2022.03.02 |