🧠Junghanacs

Recent Notes

#버전관리: 컨벤셔널 커밋 변경-로그 관리 - #magit #gitcliff

Jun 11, 20239 min read

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

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

히스토리

[2024-06-23] : 검토

환경 설정 :리눅스 :이맥스

  • git-cliff 기반

git-cliff 설치 그리고 이맥스와 연동

[2024-06-01 Sat 18:49]

컨벤셔널-커밋

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

References

만만하지 않네! 터미널에서 해야 하나? 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

Changelog.md 파일 관리 방법

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

Related-Notes

References

NO_ITEM_DATA:commitlint/config-conventional

Backlinks