https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md
커밋 메시지를 잘 적는건 중요하다. 형식을 정해두고 커밋을 할 경우 더 읽기 쉽고 한 눈에 들어오게 된다.
위의 문서를 참고하여 커밋메시지 가이드라인에 대해 간단하게 정리해보려고 한다!
위에서는 개념을 정리하고, 밑에서는 다양한 예제를 보며 커밋메시지에 익숙해지려고 한다.
커밋메시지 구성요소
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>- header는 필수이며, 헤더 내부의 scope는 선택사항
- body가 있고
- footer에는 issue에 대한 closing reference가 포함되어야 한다
간단한 예시
docs(changelog): update changelog to beta.5
fix(release): need to depend on latest rxjs and zone.js
The version in our package.json gets copied to the one we publish, and users need the latest of these.
주의: 커밋 메시지의 줄은 100자를 넘을 수 없다.
100자를 넘지 않게 작성함으로써 GitHub 등 다양한 Git도구에서 메시지를 더 쉽게 읽을 수 있다.
커밋메시지 구성요소: 헤더
1. Type
타입의 종류는 다음 중 하나여야한다
- build: 빌드 시스템 또는 외부 종속성에 영향을 미치는 변경 사항 (guilp, broccoli, npm)
- ci: CI 구성 파일 및 스크립트에 대한 변경 사항(Travis, Circle, BrowserStack, SauceLabs)
- docs: 문서만 변경됨
- feat: 새로운 기능
- fix: 버그 수정
- perf: 성능을 향상시키는 코드 변경
- refactor: 버그를 수정하지 않고 기능을 추가하지도 않는 코드 변경
- style: 코드의 의미에 영향을 주지 않는 변경 사항(공백, 포맷팅, 세미콜론 누락 등)
- test: 누락된 테스트를 추가하거나 기존 테스트를 수정
+) chore:
- chore뜻: 하기 싫은 일
- chore는 생산코드 변경없이 grunt tasks를 업데이트 할 때 쓰인다고 한다(updating grunt tasks etc; no production code change)
- grunt task는 외부 사용자에게 표시되는 내용이 없음을 뜻함
- tool 변경이나 구성변경, 실제로 생산에 영향미치지 않는 사항에 대한 변경에 사용됨
- .gitignore나 .gitattributes를 수정
- 수정사항이 포함되지 않은 기존기능의 구현
- private internal 메소드를 만듦
- 그 외에 간단한 리팩토링 용도로 사용된다고 한다.
- 참고: https://stackoverflow.com/questions/26944762/when-to-use-chore-as-type-of-commit-message
+) 이전 커밋을 되돌리는 경우
- revert:로 시작해야하며, rever:뒤에는 되돌린 커밋의 헤더가 와야함
- body에는 This reverts commit <hash> 라고 적혀있어한다 (되돌려진 커밋의 SHA)
예시
revert: Fix: firebase관련 submodule 업데이트
This reverts commit 7b13046j25a81a427144e6e2111e36fdd3eeafb7
2. Scope(범위) - 생략가능
커밋메시지를 조회 시 변경된 위치를 보여주면 훨씬 알아보기 쉽다.
scope는 어디가 변경되었는지에 관한 부분이 모두 들어갈 수 있다.
영향을 받는 npm 패키지 이름 (커밋 메시지에서 생성된 변경로그를 읽는 사람이 인식하는 영향)
지원되는 범위 목록은 다음과 같다
- animations
- common
- compiler
- comlier-cli
- core
- elements
- forms
- http
- language-service
- platform-browser
- platform-browser-dynamic
- platform-server
- platform-webworker
- platform-webworker-dynamic
- router
- service-worker
- upgrade
패키지 이름을 사용하는 규칙에는 몇 가지 예외가 있다:
- packaging: 모든 패키지에서 npm 패키지 레이아웃을 변경하는 사항(공개 경로 변경, 모든 페이지에 대한 package.json 변경, d.ts 파일/형식 변경, 번들 변경 등)에 사용된다
- Changelog: CHANGELOG.md의 release notes를 업데이트 하는 데 사용
- aio: repo의 /aio 디렉터리 내부의 docs-app(angular.io) 관련 변경 사항에 사용
- none/empty string: 모든 패키지에 걸쳐 사용되는 style, test, refactor 변경에 유용함
3. Subject
제목에는 변경에 대한 간결한 설명을 넣음.
주의점
- 명령형, 현제시제 사용 (change o, changed x, changes x)
- 첫 글자 대문자 금지
- 끝에 (.) 점 찍지말기
커밋메시지 구성요소: Body
- subject와 마찬가지로 명령형, 현제시제
- 변화에 대한 동기 포함, 이전 행동과 대조해야함
커밋메시지 구성요소: Footer
- footer에는 주요 변경사항에 대한 정보가 포함
- 이 커밋이 close되는 GitHub의 이슈를 참조할 수 있음
- 주요 변경사항은 BREAKING CHANGE: + (공백or줄바꿈 두 개)로 시작한다
- 나머지 커밋 메시지는 주요변경사항 적기
Signing the CLA
- 풀리퀘를 보내기 전 Contributor License Agreement (CLA)에 서명하자!
- 코드의 모든 변경사항을 승인하려면 CLA에 서명해야함
- 빠른 과정이니까 꼭 하기
예제 살펴보기
Angular 커밋 메시지 규약을 아주 잘 지킨 예시는 먼곳에 있지 않다. 바로 커밋메시지에 대해 적은 깃허브의 commit기록을 보면 된다
쉬운 예제를 하나씩 살펴보도록 하자
예제1: docs
- docs는 문서만 변경되었을 때 날리는 커밋이다
- changelog라는 md파일을 수정했다(release 버전을 관리하는 문서인 것 같다)
- body와 footer는 보이지않음 -> 헤더만 필수라는 걸 알 수 있다
예제2: chore
- 이 커밋은 버전번호를 올렸다고 한다
- chore는 안중요한 변경에서 쓰이는 타입이다
- router 위치에서 변경이 일어났음을 scope로 알려준다
chore: add Oyster build script
chore: .gitignore에 ~~추가
예제3: perf
- perf는 성능을 향상시키는 코드변경의 경우 사용한다
- trackBy 계산을 최소화했다고 적혀있고, body에는 호출횟수를 최소화하기 위해 코드를 재구성하였다고 적혀있다.
- core 위치에서 변경이 일어났음을 알려준다
예제4: build
- major dependencies가 아닌 것들을 모두 업데이트 하였다.
- build는 빌드 시스템 또는 외부 종속성에 영향을 미치는 변경 사항일 경우의 타입이다
- 외부종속성들과 관련한 yml 파일들을 수정하여 버전을 변경한 것을 볼 수 있다
예제5. feat
- forbidOrphanComponents라는 옵션을 추가하였다는 커밋 내용이다.
- feat는 새로운 기능이 추가되었다는 타입이다
- bazel 디렉터리에 대한 변경사항임을 scope로 알려준다
그 외의 추가 예제
docs: explain hat wobble
feat: add beta sequence
fix: remove broken confirmation message
refactor: share logic between 4d3d3d3 and flarhgunnstow
refactor: Reorganize folder layout
refactor: Rename component
style: convert tabs to spaces
style: add missing semicolons
style: Update style sheets
test: ensure Tayne retains clothing
build: Install new dependency
인텔리제이에는 git commit template을 적용시킬 수 있다고 한다. 일일이 치기 귀찮은 사람들은 템플릿을 사용해도 좋을 것 같다
https://plugins.jetbrains.com/plugin/9861-git-commit-template
Git Commit Template - IntelliJ IDEs Plugin | Marketplace
Create a commit message with the following template: <type>(<scope>): <subject> <BLANK LINE> <body> <BLANK LINE> <footer>.
plugins.jetbrains.com
찾아보니 git bisect라는 것도 있고, CHANGELOG.md라는 것도 있었다.
모두 공부해서 정리하고싶지만, 지금은 기능구현이 우선이기 때문에 나머지는 차근차근 공부해보려고 한다.
참고한 자료들:
https://sparkbox.com/foundry/semantic_commit_messages
Semantic Commit Messages
See how a minor change to your Git commit message style can make you a better programmer.
sparkbox.com
Git 커밋 메세지 규약 정리 - The AngularJS commit conventions.
The AngularJS commit conventions.
velog.io
'협업 > Git' 카테고리의 다른 글
| [Git] .gitignore 적용시키기 공부 (0) | 2024.01.28 |
|---|---|
| [GitHub] 커밋 메시지 바꾸기: amend, rebase, cherrypick (1) | 2023.11.01 |
| [GitHub] 테코톡 보면서 깃허브 공부하기 (0) | 2023.11.01 |
| .gitignore 적용 안될 때 대처법 (0) | 2023.08.13 |
