귀하의 git 기록은 이미 귀하의 변경 로그입니다 — 나는 그것을 추출하기 위해 제로 딥 CLI를 만들었습니다

작성자

카테고리:

← 피드로
DEV Community · benjamin · 2026-06-15 개발(SW)
Cover image for Your git history is already your changelog — I built a zero-dep CLI to extract it

benjamin

You ship a release. You mean to write the changelog “later.” Three weeks pass, someone asks “what actually changed in 1.2?”, and now you’re scrolling git log trying to reconstruct it from memory.

Here’s the thing: if your commits look anything like feat: ... / fix: ... (Conventional Commits), the changelog already exists — it’s sitting in your git history. It just needs extracting.

The tools that do this each ask for something first:

  • git-cliff is genuinely great — but it’s a Rust binary you install via cargo or a release download, plus a cliff.toml to configure.
  • standard-version — deprecated.
  • release-please — powerful, but it wants GitHub Actions and a release-PR workflow.

I wanted one command, no setup. So I built changelg:

npx changelg --release v1.2.0

Enter fullscreen mode Exit fullscreen mode

## v1.2.0 (2026-06-15)

### ⚠ BREAKING CHANGES

- **auth:** existing tokens are invalidated on deploy. (6667b72)

### Features

- **api:** add cursor pagination (a1b2c3d)

### Bug Fixes

- handle an empty response body (e4f5a6b)

Enter fullscreen mode Exit fullscreen mode

That’s commits since your latest tag, grouped, scopes bolded, hashes linked to your remote. Redirect it into a file, prepend it to CHANGELOG.md, done.

How it works

  • Range: changelg (since the latest tag), changelg v1.1.0 (since a ref), or changelg v1.1.0..v1.2.0 (explicit).
  • Grouping: feat → Features, fix → Bug Fixes, perf → Performance. A ! or a BREAKING CHANGE: footer surfaces a dedicated ⚠ BREAKING CHANGES section — showing the breaking note, not just the subject.
  • Noise control: docs / chore / refactor / etc. are hidden by default; --all brings them in.
  • Links: commit hashes auto-link to your origin remote, or --no-links for plain short hashes.

Zero dependencies, both ecosystems

It’s pure standard library — git log plus a parser. No Rust toolchain, no config file, no token, no Actions. The Node and Python ports are behavior-identical (same flags, byte-identical output):

npx changelg              # Node >= 18
pip install changelg      # Python >= 3.8

Enter fullscreen mode Exit fullscreen mode

How do you handle changelogs today — a tool, by hand, or “the git log is the changelog”? And if you don’t use Conventional Commits, would a tool like this nudge you toward them, or is that a non-starter?

원문에서 계속 ↗

코멘트

답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다