우테코 프리코스를 본격적으로 수행하기에 앞서 요구사항을 읽어보니 다음과 같은 조건이 있었다.
AngularJS Git Commit Message Conventions을 참고해 커밋 메시지를 작성한다.
그래서 영어는 잼병이지만.. 다음 커밋 방법에 대해서 우선 천천히 읽어보며 정리를 해보려고 한다.
목표
- 스크립트로
CHANGELOG.md
를 작성 할 수 있다. git bisect
으로 중요도가 떨어지는 commit을 무시 할 수 있다.- commit 기록을 확인(browsing)할 때 더 나은 정보를 제공할 수 있다.
git bisect 관련해서는 다음 블로그 참고.
CHANGELOG.md
작성하기
changelog.md를 작성하는 데에는 3가지의 section을 이용된다.
- 새로운 특징 (new features)
- 버그 수정 (bug fixes)
- 주요 변경 내용 (breaking changes)
배포 시, 스크립트를 사용해서 관련 커밋에 대한 링크와 함께 위 내용들을 생성할 수 있다.
물론, 실제로 배포하기 전에 변경 내역을 수정하고 배포할 수도 있습니다.
아래 명령어는 최근 배포 이후의 제목 목록(subjects list)을 출력합니다. (제목: 커밋 메시지의 첫번째 줄)
// 원문
git log <last tag> HEAD --pretty=format:%s
// 수정
git log <last tag>..HEAD --pretty=format:%s
--pretty 옵션 관련해서는 Git 공식 문서 참고
아래 명령어는 이번 릴리즈의 새로운 특징들을 출력합니다.(New features in this release)
git log <last release> HEAD --grep feature
--grep
은 커밋 메시지 안의 텍스트를 검색하는 속성으로 위의 명령어에서는 'feature을 검색한다'는 의미이다.
즉 의미는 'last release에서 지금까지의 커밋 중 feature이 들어간 커밋을 검색한다.' 이다.
번외로 내 프로젝트에서 git log --grep feat
을 해봤는데 feat이 들어간 커밋만 검색된다.
중요하지 않은 커밋 식별하기
중요하지 않은 커밋은 주로 로직의 변화가 없는 커밋입니다.
- 포매팅 변화 (공백이나 빈 줄의 추가, 제거, 들여쓰기)
- 세미콜론 누락
- 주석
그래서 변경 내역(some changes)을 조회할 때 위와 같이 중요하지 않은 커밋은 무시해도 됩니다.
git bisect
를 사용하여 이진 탐색할 때, 다음과 같이 중요하지 않은 커밋을 무시할 수 있습니다.
git bisect skip $(git rev-list --grep irrelevant <good place> HEAD)
- git bisect은 커밋을 2진 탐색하며 커밋에 문제가 있는지 없는지 확인하기 위해 사용한다.
- 위의 명령어는 탐색을할 때 'irrelevant'라는 문구가 있는 커밋은 무시하라는 뜻이다.
히스토리를 조회할 때 더 많은 정보를 제공
커밋을 확인할 때 더 많은 정보를 제공하기 위해, 일종의 문맥 정보(context information)를 추가한다.
다음은 angular의 최근 커밋들 중 일부이다 :
- Fix small typo in docs widget (tutorial instructions)
- Fix test for scenario.Application - should remove old - iframe
- docs - various doc fixes
- docs - stripping extra new lines
- Replaced double line break with single when text is fetched from Google
- Added support for properties in documentation
위 메세지들은 어디가 어떻게 바뀌었는지 명시하였지만 정해진 형식이 없다.
다른 메세지들도 봐 보자:
- fix comment stripping
- fixing broken links
- Bit of refactoring
- Check whether links do exist and throw exception
- Fix sitemap include (to work on case sensitive linux)
이 메시지만 보고는 어느 부분이 변했는지 알 수 없다.
따라서 docs, docs-parser, compiler, senario-runner와 같이 어디가 변경됐는지 알려주는게 좋을 것이다.
물론, 변경된 파일들을 일일히 찾아보면 알 수 있겠지만 느릴 것이다.
그리고 git history들을 보면 어디가 변했는지 명시하려고 하는건 보이지만, 단지 규약(convention)이 없을 뿐이다.
Commit 메세지의 형식
<type>(<scope>): <subject>
<body>
<footer>
커밋 메시지의 각 줄은 100자를 넘기지 말아야 한다. 그래야 읽기 쉽다.
Commit 메세지 Header 작성법 (Subject line)
<type>(<scope>): <subject>
<type> 에 들어갈 수 있는 항목들
- feat : 새로운 기능 추가
- fix : 버그 수정
- docs : 문서 관련
- style : 스타일 변경 (포매팅 수정, 들여쓰기 추가, …)
- refactor : 코드 리팩토링
- test : 테스트 관련 코드
- chore : 그 외 자잘한 수정
- build : 빌드 관련 파일 수정
- ci : CI 설정 파일 수정
- perf : 성능 개선
새로운 Angular 9 규약에서는 chore가 삭제되고, build, ci, perf가 추가되었다.
<scope> 에 들어갈 수 있는 항목들
변경사항이 있는 어떤 위치든 적을 수 있음. 단, 생략 가능함.
예를 들어, $location, $browser, $compile, $rootScope, ngHref, ngClick, ngView, 등등..
함수나 메서드, 클래스도 기재 가능함.
<subject> 에 들어갈 수 있는 항목들
- 명령문, 현재 시제로 작성한다.예를 들어, 변경되었으면 : "change"를 사용한다. "changed"나 "changes"를 사용하지 않습니다.
- 첫글자를 대문자로 쓰지 마세요. 소문자로 쓰세요.
- 마지막에 마침표(.)를 붙이지 마세요
Commit 메세지 Body 작성법 (Message body)
<body>
- <body>에는 Commit의 주 내용을 적는다.
- 명령문, 현재 시제로 작성한다.
- 변경된 이유와 변경 전과의 차이를 기재한다.
참고 링크
Commit 메세지 Footer 작성법 (Message footer)
<footer>
- <footer>에는 주요 변경 내역과 어떤 이슈를 해결 했는지 기재한다.
주요 변경 내역(Breaking Changes)
모든 주요 변경 내역들은 다음과 함께 하단에 언급되어야 한다.
- 변경점 (description of the change)
- 변경 사유 (justification)
- 마이그레이션 지시 (migration instructions)
아래는 예시이다:
BREAKING CHANGE: isolate scope bindings definition has changed and
the inject option for the directive controller injection was removed.
To migrate the code follow the example below:
Before:
scope: {
myAttr: 'attribute',
myBind: 'bind',
myExpression: 'expression',
myEval: 'evaluate',
myAccessor: 'accessor'
}
After:
scope: {
myAttr: '@',
myBind: '@',
myExpression: '&',
// myEval - usually not useful, but in cases where the expression is assignable, you can use '='
myAccessor: '=' // in directive's template change myAccessor() to myAccessor
}
The removed `inject` wasn't generaly useful for directives so there should be no code using it.
해결된 이슈(Referencing Issues)
해결된 이슈가 있다면 <footer>에 Closes #<이슈번호>
로 기재한다.
Closes #234
// 해결된 이슈가 여러가지라면
Closes #123, #245, #992
아래는 잘 작성한 사례의 일부이다.
// #1
feat($browser): onUrlChange event (popstate/hashchange/polling)
Added new event to $browser:
- forward popstate event if available
- forward hashchange event if popstate not available
- do polling when neither popstate nor hashchange available
Breaks $browser.onHashChange, which was removed (use onUrlChange instead)
// #2
fix($compile): couple of unit tests for IE9
Older IEs serialize html uppercased, but IE9 does not...
Would be better to expect case insensitive, unfortunately jasmine does
not allow to user regexps for throw expectations.
Closes #392
Breaks foo.bar api, foo.baz should be used instead
// #3
feat(directive): ng:disabled, ng:checked, ng:multiple, ng:readonly, ng:selected
New directives for proper binding these attributes in older browsers (IE).
Added coresponding description, live examples and e2e tests.
Closes #351
// #4
style($location): add couple of missing semi colons
후기
여태까지 비슷한 느낌으로 commit을 해오긴 했지만 본격적으로 알아본 느낌이 든다.
실컷 배포하고 commit 했지만 tag를 통해 버전관리를 하거나 git bisect를 사용해본 적은 없어서 조금 반성하게 되었다.
어떻게 보면 내가 했던 commit 들이 조금 더 체계적으로 작성해야 되겠구나~.. 를 느낀 순간이였다.
git은 협업의 기초이니까 잘 알아 두면 정말 좋을 것 같다.
'Programming' 카테고리의 다른 글
[우테코 프리코스/7기] 프리코스 2주 차 회고 (1) | 2024.11.02 |
---|---|
[우테코 프리코스/7기] 프리코스 1주 차 회고 (4) | 2024.10.24 |
[우테코 프리코스/7기] 본격적인 시작 전 준비 (0) | 2024.10.15 |
"NET::ERR_CERT_DATE_INVALID" 에러 & SSL 인증서 재발급 (0) | 2024.09.13 |
내가 생각하는 프로젝트 규모에 따른 프론트 기술스택 선정기준 (0) | 2024.08.24 |