AngularJS Git Commit Message 규칙 원문 번역본
AngularJS에서의 Git commit 메시지 규칙 문서를 읽어도 감이 오지 않아 조금 더 공부해보기로 했다.
기본 git 명령어 정리
시작하기 전 기본적인 git 명령어를 알고 싶다면 위 글을 참고한 뒤 공부한다면 이해가 쉬울 것이다.
커밋 메시지 규칙이 중요한 이유
개발자들은 커밋할 때 많은 내용을 담으려고 노력하지만, 코드 변경 사항을 파악하기 어려우면 코드 관리가 비효율적일 수 있다.
이 문제를 해결하기 위해 체계적인 Git 커밋 메시지 규칙이 필요하게 되었고, 해당 규칙을 따르면 코드 변경 내용을 명확하게 기록할 수 있어 효율성을 크게 향상시킬 수 있다.
커밋 메시지 규칙을 잘 지키면 코드 리뷰나 협업 과정에서도 커뮤니케이션이 원활해지고, 이후 수정 시에도 변경 이력이 분명해져 코드 관리가 수월해진다.
좋은 커밋 메시지 작성하기 위한 7가지 약속
Git 커밋 메시지를 잘 작성하는 것은 코드 유지보수와 협업에서 중요한 역할을 한다. Chris Beams이 제안한 7가지 룰에 대해 알아보려고 한다.
- 제목과 본문을 한 줄 띄워 분리하기
제목과 본문 사이에 빈 줄을 추가하는 것은 생각보다 효과적인 테크닉이다.
Git commit의 man 페이지에서는 제목과 본문 사이에 빈 줄을 넣을 것을 권장하고 있다.
이 공백은 제목을 보다 깔끔하게 구분하고, git log와 같은 명령어로 로그를 확인할 때 더 보기 좋은 형식을 만들어준다.
feat: Huge capability implementation
I think I can change the world by implementing a huge function.
<footer>- 제목은 영문 기준 50자 이내로
제목은 50자 이내로 작성하는 것이 좋다.
이 제한은 커밋 메시지를 더 간결하게 만들고, 요약된 형태로 변경 사항을 파악하기 쉽게 한다.
- 제목 첫 글자는 대문자로
제목의 첫 글자는 반드시 대문자로 작성한다.
영어권에서는 제목의 첫 글자를 대문자로 쓰는 것이 일반적이며, 이를 지키지 않으면 문법적으로 어색하게 느껴질 수 있다.
- 제목 끝에 마침표 금지
제목에는 마침표를 사용하지 않는다.
제목은 간결하게 요약된 정보이므로 마침표가 불필요하다.
- 제목은 명령형으로 작성
제목은 명령형으로 작성해야 한다.
이는 Git의 기본 메시지 형식과 일관성을 유지하기 위함이다.
예를 들어, “Fixed bug” 대신 “Fix bug”로 작성한다.
“If applied, this commit will…”이라는 문장을 사용해 제목을 완성해보면 도움이 된다.
- 본문은 영문 기준 72자마다 줄 바꾸기
커밋 메시지의 본문은 72자를 기준으로 줄을 바꾸는 것이 좋다.
Git은 자동으로 줄바꿈을 해주지 않기 때문에, 적절한 위치에서 줄을 바꾸어 가독성을 높인다.
- 본문은 무엇을, 왜에 맞춰 작성하기
커밋 메시지의 본문에서는 무엇을 변경했는지, 그리고 왜 그 변경이 필요했는지를 설명해야 한다.
어떻게 변경했는지보다 무엇을, 왜 변경했는지가 더 중요하다.
코드는 변경된 방식을 설명하지만, 변경된 이유는 커밋 메시지에서만 알 수 있다.
fix: Fix huge features and security patches
A security patch is carried out to eliminate the possibility of potentially
Ant-Man entering the port due to a catastrophic error in the Huge capability
implementationAngularJS Git Commit Message 구조
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>커밋 메시지는 위와 같은 구조로 작성한다.
커밋 메시지 작성 방법
git commit -m '(subject)' -m '(description or body)' -m '(footer)'git commit -m '(subject)
(description or body)
(footer)'
되돌리기(revert)
- 되돌리기 커밋은
revert:로 시작하며, 뒤에 되돌릴 커밋의 헤더가 따라온다. - 본문에는
이 커밋은라고 작성한다.커밋을 되돌립니다.
git commit -m 'revert: fix: correct typo in user guide' \
-m 'This commit reverts the changes made in commit f27beee79b3a7da4cb7aa29d6ab2e79c242003eb.'메시지 헤더
헤더에는
type
| 타입 | 설명 |
|---|---|
| feat | 새로운 기능 추가 |
| fix | 버그 수정 |
| docs | 문서화 작업 |
| style | 코드 포맷, 세미콜론 누락 등 스타일 변경 (기능 변경 없음) |
| refactor | 코드 리팩토링 (기능 변화 없음) |
| test | 테스트 코드 추가 |
| chore | 빌드 작업 또는 패키지 관리자 설정 등 유지보수 작업 |
scope
필요 없을 때는 생략하거나, 범위가 너무 넓다면 *로 대체할 수 있다.
subject
- 매우 짧은 변경 사항 설명
- 명령형 현재 시제 사용: “change”로 작성, “changed”나 “changes”는 사용하지 않음
- 첫 글자를 대문자로 하지 않음
- 끝에 마침표(.) 사용하지 않음
예를 들어, 아래와 같이 작성할 수 있다.
git commit -m "fix: correct typo in user guide"메시지 본문
body
- 명령형 현재 시제를 사용한다: “change”로 작성, “changed”나 “changes”는 사용하지 않음
- 변경 이유 및 이전 동작과의 차이점 포함
git commit -m 'fix: correct typo in user guide' \
-m 'Change \'recieve\' to \'receive\'.'메시지 푸터
브레이킹 체인지 (Breaking Changes)
브레이킹 체인지는 소프트웨어 변경 내용이 이전 버전과 호환되지 않는 경우를 의미한다. 예를 들어 API 엔드포인트가 변경되거나, 함수의 매개변수 타입이 변경된 경우 등이 있다.
커밋 메시지 푸터에 BREAKING CHANGE:로 시작하여 변경 사항과 마이그레이션 방법을 설명해야 한다.
BREAKING CHANGE: isolate scope 바인딩 정의가 변경되었으며
directive 컨트롤러의 주입 옵션이 제거되었습니다.
마이그레이션 방법:
이전:
scope: {
myAttr: 'attribute',
myBind: 'bind',
myExpression: 'expression',
myEval: 'evaluate',
myAccessor: 'accessor'
}
이후:
scope: {
myAttr: '@',
myBind: '@',
myExpression: '&',
myAccessor: '='
}이슈 참조
Git Repository의 Issues에서 확인할 수 있는 이슈 코드는 커밋 메시지 푸터에서 “Closes”라는 키워드를 사용해 참조할 수 있다.
위 내용의 Issue code는 #1이다.
해결된 버그는 푸터에서 “Closes”라는 키워드로 별도의 줄에 나열해야 한다. 예를 들어:
Closes #234 //단일 이슈 처리
Closes #123, #245, #992 //여러 이슈가 있을 경우 처리“closes <해당 코드>” 또는 ~~”fix <해당 코드>“~~가 포함되면 Git Repository의 Issues에서 해당 이슈가 자동으로 닫힌다.
정리
Git을 공부하면서 커밋 메시지에 대해 깊이 고민해본 적이 없었다. 아마도 아직 협업을 제대로 경험하지 않아서일 것이다. 이번 기회에 커밋 작성법을 참고하여 더 효과적인 버전 관리를 시도할 예정이다. 하지만 여전히 의문이 남는다. 과연 한국어로도 이 규칙을 지키며 커밋 메시지를 작성할 수 있을까? 대부분의 사람들은 이 규칙을 지키면서 한국어를 유연하게 적용한다고 알고 있다. 이 부분은 다음에 더 깊이 알아볼 계획이다.
참고
cbeams – How to Write a Git Commit Message
Vojta Jina, Igor Minar – AngularJS Git Commit Message Conventions