--- title: "#버전관리: 컨벤셔널커밋 시멘틱버저닝 체인지로그 ¤git-cliff" url: "https://notes.junghanacs.com/notes/20230612T070000" author: "Junghan Kim" date: "2023-06-12T07:00:00+09:00" lastmod: "2025-07-18T00:00:00+09:00" tags: ["bib","style","version"] description: "컨벤셔널 커밋, 시멘틱 버저닝, 체인지로그 규칙을 한 흐름으로 엮어 버전 관리 원칙을 정리한 자료." --- > [!abstract] 이 노트에 대하여 > > 컨벤셔널 커밋, 시멘틱 버저닝, 체인지로그 스펙을 한 흐름으로 묶어 버전 관리 규칙을 정리한다. 커밋 메시지부터 릴리스 기록 자동화까지 일관된 개발 습관을 세우려는 의도가 읽힌다. ## BIBLIOGRAPHY - “Eki3z/Git-Cliff.El.” 2025. . - “Keep a Changelog 체인지로그 스펙.” n.d. Accessed January 20, 2025. . - “Orhun/Git-Cliff: A Highly Customizable Changelog Generator That Follows Conventional Commit Specifications.” 2023. . - Preston-Werner, Tom. n.d. “Semantic Versioning 시멘틱 버저닝.” Accessed January 20, 2025. . - NO_ITEM_DATA:commitlint/config-conventional ## Keep a Changelog 체인지로그 스펙 ([“Keep a Changelog 체인지로그 스펙” n.d.](https://notes.junghanacs.com/notes/20230612T070000#citeproc_bib_item_2)) - 동료가 git 로그를 changelogs에 덤프하게 내버려 두지 마세요. ## Semantic Versioning 시멘틱 버저닝 ([Preston-Werner n.d.](https://notes.junghanacs.com/notes/20230612T070000#citeproc_bib_item_4)) - Preston-Werner, Tom - Semantic Versioning spec and website ## 히스토리 - [2023-06-12 Mon 07:00] 어떻게 커밋 메시지를 관리할 것이며 변경사항을 자동화 할 것인가? 그것도 이맥스에서 Magit 을 사용하면서 말이다. 그래야 편하게 통일 할 수 있다. 깃허브 주소는 여기다. [^fn:1] 커밋 메시지를 작성하는 방법을 배울 필요가 있다. 가이드라인이 있다. All notable changes to this project will be documented in this file. See [conventional commits]() for commit guidelines. - [#버전관리](https://notes.junghanacs.com/meta/20240821T162824) ## `git-cliff` 설치 그리고 이맥스와 연동 [2024-06-01 Sat 18:49] - git-cliff 설치 할 때 DEB 다운 받아서 설치하라. - 이맥스 패키지와 사용 방법은 연구 할 것 ### orhun/git-cliff: A highly customizable Changelog Generator that follows Conventional Commit specifications ([“Orhun/Git-Cliff: A Highly Customizable Changelog Generator That Follows Conventional Commit Specifications” 2023](https://notes.junghanacs.com/notes/20230612T070000#citeproc_bib_item_3)) ### eki3z/git-cliff.el ([“Eki3z/Git-Cliff.El” 2025](https://notes.junghanacs.com/notes/20230612T070000#citeproc_bib_item_1)) - Zhang, Eki - Genarate and update git repository CHANGELOG.md with git-cliff ## 컨벤셔널-커밋 ### kijimaD-roam 폴더를 확인하라 실마리를 잡았다. _home/junghan/sync/code/linter/kijimaD-roam_.githooks/commit_msg.txt ```text # Conventional commits cheat sheet... # build: ビルド # chore: 雑事(カテゴライズする必要ないようなもの) # ci: CI # docs: ドキュメント # feat: 新機能 # fix: バグフィックス # perf: パフォーマンス # refactor: リファクタリング # revert: コミット取り消し(git revert) # style: コードスタイル修正 # test: テスト # Conventional commits cheat sheet... # build: 빌드 # chore : 잡사 (범주화 할 필요가없는 것) # ci: CI # docs: 문서 # feat: 새로운 기능 # fix: 버그픽스 # perf: 성능 # refactor: 리팩토링 # revert : 커밋 취소 (git revert) # style: 코드 스타일 수정 # test: 테스트 # https://www.conventionalcommits.org/ko/v1.0.0/ # https://www.conventionalcommits.org/ja/v1.0.0/ # https://gist.github.com/minop1205/5fc4f6ef0ec89fb1738833ba25ae00a0 ``` ```text git config --local core.hooksPath .githooks git config --local commit.template .githooks/commit_msg.txt ``` ### How-to Conventional Commits [2023-07-09 Sun 21:11] [コミットメッセージ規約 · GitHub](https://gist.github.com/minop1205/5fc4f6ef0ec89fb1738833ba25ae00a0) 번역함 #### Commitlint Install [2023-07-09 Sun 21:13] $ npm install -g commitlint 설정 파일은?! #### Conventional Commits 커밋 메시지의 유효성을 검사하려면 `commitlint` ( )를 사용합니다. 또한 커밋 메시지는 다음 약관을 준수합니다. #### Format 커밋 메시지의 포멧은 다음과 같습니다. ```text [optional scope]: [optional body] [optional footer(s)] ``` `type` , `subject` 는 필수입니다. `body` , `footer` 를 넣는 경우는 각각 빈 라인을 사이에 넣습니다. ##### type `type` 은 lowerCase 로 표기하며 다음 중 하나가 필요합니다. | name | description | |----------|-----------------------| | build | 빌드 | | ci | CI | | chore | chore (분류할 필요가 없는 것들) | | docs | 문서 | | feat | 기능 | | fix | 버그 수정 | | perf | 성능 | | refactor | 리펙터링 | | revert | revert（git revert） | | style | 코스 스타일 수정 | | test | 테스트 | ```text : some message # fails foo: some message # fails FIX: some message # fails fix: some message # passes ``` ##### scope `type` 에는 추가 컨텍스트 정보를 나타내는 `scope` 를 포함할 수 있습니다. `scope` 는 `type` 뒤에 괄호로 표시하고 lowerCase 로 표기합니다. ```text fix(SCOPE): some message # fails fix(scope): some message # passes ``` ##### subject `subject` 는 필수이며 명령형·현재계의 동사로 시작합니다(예: 'changed' 또는 'changes' 대신 'change'로 시작합니다.) 커밋 메시지는 '무엇을 했는가'를 기록하는 것보다 '이 커밋을 적용하면 어떻게 되는가'를 나타내는 것이 바람직하기 때문입니다. `subject` 는 lowerCase 로 표기합니다. ```text fix: # fails fix: Some Message # fails fix: SomeMessage # fails fix: SOMEMESSAGE # fails fix: some message # passes ``` `subject` 의 끝은 `.` 로 끝나서는 안됩니다. ```text fix: some message. # fails fix: some message # passes ``` ##### body `subject` 에 대한 자세한 정보가 필요한 경우 `body` 섹션에 설명하십시오. ```text fix: correct minor typos in code see the issue for details on the typos fixed closes issue #12 ``` ##### footer `footer` 에 Breaking Changes 에 대한 정보와 이 커밋이 닫힌 GitHub 과제를 참조하는 장소이기도합니다. Breaking Changes 는 먼저 `BREAKING CHANGE:` 라는 단어로 시작하고 공백이나 줄 바꿈으로 시작합니다. 파괴적인 변경은 모두 `footer` `BREAKING CHANGE` 블록으로 기재해야 합니다. `BREAKING CHANGE` 블록에는 변경 설명, 변경 이유, 마이그레이션 고려 사항 등이 포함됩니다. ```text 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. ``` 닫힌 GitHub Issue 에 대한 참조를 추가하려면 다음과 같이 `Closes` 키워드를 선두로 해서 기술해 주세요. ```text Closes #234 ``` 여러 Issue 에 대한 참조를 추가하려면 쉼표로 구분하십시오. ```text Closes #123, #245, #992 ``` ##### BREAKING CHANGE 선택적 본문 또는 바닥글 섹션의 시작 부분에 `BREAKING CHANGE:` 라고 하는 텍스트를 가지는 커밋은, 호환성이 없는 파괴적인 변경을 포함하는 것을 나타냅니다. `BREAKING CHANGE` 어떤 종류의 커밋에 포함될 수 있습니다. ```text fix: some message BREAKING CHANGE: It will be significant ``` \*\* - (NO_ITEM_DATA:commitlint/config-conventional) - Conventional Commits - Angular Commit Message Conventions # - Writing Git commit messages ### 만만하지 않네! 터미널에서 해야 하나? magit 님께 여기 예제가 있다. 그냥 magit 으로 하는대까지 해보자. ### 다시 minemacs [2023-06-12 Mon 12:27] 이 친구가 하는 것이 도움이 될 것이다. /home/junghan/sync/man/dotsamples/vanilla/minemacs/modules/me-vc.el 봐봐라. 아 git-commit 패키지가 이 역할을 하는데! 그동안 뭐한거냐?! ### 어떻게 커밋해야 되는가? [2023-06-12 Mon 12:13] 물론 마깃으로 해야 한다. 그래야 한다. 그러고 싶다. 트렌지언트 메뉴는 효과적인 옵션이다. 좋다. 일단 해보자. 키바인딩은 `SPC g /` 로 박아 놨다. ## 체인지로그 ### 질문: Emacs Magit 에서 활용 가능한 옵션은 무엇인가? 2023-06-12 찾았다 질문이 어렵다. 매번 그렇다. 누가 뭘 쓰는지는 관심 가질 게 없다. 이맥스에서 통합 가능 여부가 중요하다. 다만 빌트인 VC 도 물론 좋으나 Magit 은 Emacs 최고의 패키지라고 하지 않는가? 나도 사실 아직 제대로 못쓰고 있지만 의도를 가지고 확실하게 접근하자. 커밋 관리가 되려면 툴의 도움이 필요하지 않겠는가? ~~이맥스에서 `자동화` 에 도움을 줄 수 있는 방법이 있는가?~~ ### Changelog Generation [2023-06-09 Fri 05:47] 다 필요 없다. 이거 만으로 훌륭하다. 이걸 위해서 쓰는 것이다. ### Tools [2023-06-09 Fri 05:48] cog 는 Minemacs 에서 사용하는 것이고 다른 것도 있다. 많다. ### Minemacs Example /home/junghan/sync/man/dotsamples/vanilla/minemacs/CHANGELOG.md ```text # Changelog All notable changes to this project will be documented in this file. See [conventional commits](https://www.conventionalcommits.org/) for commit guidelines. - - - ## v0.4.0 - 2023-05-27 #### Bug Fixes - *(citar)* avoid using `all-the-icons` until it is loaded - (960d978) - Abdelhak Bougouffa ``` ### Changelog.md 파일 관리 방법 [2023-09-07 Thu 18:45] [Keep a Changelog](https://keepachangelog.com/ko/1.0.0/) 읽어보라. markdown-changelog 패키지 [^fn:1]: