#버전관리 컨벤셔널커밋 시멘틱버저닝 체인지로그 스펙

BIBLIOGRAPHY

“Keep a Changelog 체인지로그 스펙.” n.d. Accessed January 20, 2025. https://keepachangelog.com/ko/1.0.0/.

“Orhun/Git-Cliff: A Highly Customizable Changelog Generator That Follows Conventional Commit Specifications.” 2023. https://github.com/orhun/git-cliff.

Preston-Werner, Tom. n.d. “Semantic Versioning 시멘틱 버저닝.” Semantic Versioning. Accessed January 20, 2025. https://semver.org/lang/ko/.

Zhang, Eki. (2023) 2025. “Eki3z/Git-Cliff.El.” https://github.com/eki3z/git-cliff.el.

NO_ITEM_DATA:commitlint/config-conventional

Keep a Changelog 체인지로그 스펙

(“Keep a Changelog 체인지로그 스펙” n.d.)

• 동료가 git 로그를 changelogs에 덤프하게 내버려 두지 마세요.

Semantic Versioning 시멘틱 버저닝

(Preston-Werner n.d.)

• Preston-Werner, Tom
• Semantic Versioning spec and website

배경

• #버전관리

어떻게 커밋 메시지를 관리할 것이며 변경사항을 자동화 할 것인가? 그것도 이맥스에서 Magit 을 사용하면서 말이다. 그래야 편하게 통일 할 수 있다. 깃허브 주소는 여기다. ¹

커밋 메시지를 작성하는 방법을 배울 필요가 있다. 가이드라인이 있다. All notable changes to this project will be documented in this file. See conventional commits for commit guidelines.

히스토리

2024-06-23 : 검토

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)

eki3z/git-cliff.el

(Zhang [2023] 2025)

• Zhang, Eki
• Genarate and update git repository CHANGELOG.md with git-cliff

컨벤셔널-커밋

TODO kijimaD-roam 폴더를 확인하라

실마리를 잡았다.

home/junghan/sync/code/linter/kijimaD-roam.githooks/commit_msg.txt

 
# 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
 

https://github.com/kijimaD/roam

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 번역함

Commitlint Install

[2023-07-09 Sun 21:13] https://github.com/conventional-changelog/commitlint#cli

$ npm install -g commitlint

설정 파일은?!

Conventional Commits

커밋 메시지의 유효성을 검사하려면 commitlint ( https://github.com/conventional-changelog/commitlint )를 사용합니다.

또한 커밋 메시지는 다음 약관을 준수합니다. https://github.com/conventional-changelog/commitlint/tree/master/%5Bcite/t:@commitlint/config-conventional%5D

Format

커밋 메시지의 포멧은 다음과 같습니다.

<type>[optional scope]: <subject>
 
[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	테스트

  : some message     # fails
  foo: some message  # fails
  FIX: some message  # fails
  fix: some message  # passes

• scope

  type 에는 추가 컨텍스트 정보를 나타내는 scope 를 포함할 수 있습니다. scope 는 type 뒤에 괄호로 표시하고 lowerCase 로 표기합니다.

  fix(SCOPE): some message  # fails
  fix(scope): some message  # passes

• subject

  subject 는 필수이며 명령형·현재계의 동사로 시작합니다(예: ‘changed’ 또는 ‘changes’ 대신 ‘change’로 시작합니다.) 커밋 메시지는 ‘무엇을 했는가’를 기록하는 것보다 ‘이 커밋을 적용하면 어떻게 되는가’를 나타내는 것이 바람직하기 때문입니다.

  subject 는 lowerCase 로 표기합니다.

  fix:               # fails
  fix: Some Message  # fails
  fix: SomeMessage   # fails
  fix: SOMEMESSAGE   # fails
  fix: some message  # passes

  subject 의 끝은 . 로 끝나서는 안됩니다.

  fix: some message. # fails
  fix: some message  # passes

• body

  subject 에 대한 자세한 정보가 필요한 경우 body 섹션에 설명하십시오.

  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 블록에는 변경 설명, 변경 이유, 마이그레이션 고려 사항 등이 포함됩니다.

  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 키워드를 선두로 해서 기술해 주세요.

  Closes #234

  여러 Issue 에 대한 참조를 추가하려면 쉼표로 구분하십시오.

  Closes #123, #245, #992

• BREAKING CHANGE

  선택적 본문 또는 바닥글 섹션의 시작 부분에 BREAKING CHANGE: 라고 하는 텍스트를 가지는 커밋은, 호환성이 없는 파괴적인 변경을 포함하는 것을 나타냅니다. BREAKING CHANGE 어떤 종류의 커밋에 포함될 수 있습니다.

  fix: some message
   
  BREAKING CHANGE: It will be significant

  **

  • (NO_ITEM_DATA:commitlint/config-conventional) https://github.com/conventional-changelog/commitlint/tree/master/%5Bcite/t:@commitlint/config-conventional%5D

  • Conventional Commits https://www.conventionalcommits.org/en/v1.0.0-beta.4/

  • Angular Commit Message Conventions https://docs.google.com/document/d/1QrDFcIiPjSLDn3EL15IJygNPiHORgU1_OOAqWjiDU5Y/edit#

  • Writing Git commit messages https://365git.tumblr.com/post/3308646748/writing-git-commit-messages

만만하지 않네! 터미널에서 해야 하나? magit 님께

https://www.adventuresinwhy.com/post/commit-message-linting/

여기 예제가 있다. 그냥 magit 으로 하는대까지 해보자.

https://magit.vc/manual/magit/Commit-Message-Conventions.html

다시 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 에서 사용하는 것이고 다른 것도 있다. 많다.

https://github.com/cocogitto/

https://github.com/orhun/git-cliff

Minemacs Example

/home/junghan/sync/man/dotsamples/vanilla/minemacs/CHANGELOG.md

# 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

TODO Changelog.md 파일 관리 방법

[2023-09-07 Thu 18:45] Keep a Changelog 읽어보라. markdown-changelog 패키지

Footnotes

1. https://github.com/liuyinz/emacs-conventional-changelog ↩