A changelog is only painful when you write it three months late. If you tag releases, most of the work is already done.
Tag what you ship#
git tag -a v1.3.0 -m "v1.3.0"
git push origin v1.3.0
Annotated tags carry a message and a date, and they give you a name for “what is in production right now”.
The log between tags is your draft#
git log v1.2.0..v1.3.0 --oneline --no-merges
That list, cleaned up, is the release note. Short, descriptive commit subjects pay off here — another reason the commit-msg habit matters.
Keep a CHANGELOG.md in the repo#
Add a section per tag, newest at the top, dated. Users of your package or app read it before upgrading; future-you reads it when something breaks and the question is “since when”. For a Laravel app, note the migrations and any .env keys a release adds, because those are the steps a deploy can trip on.
The habit that makes it work#
Write the entry at tag time, while the diff is fresh. A changelog maintained per release is ten lines of work; reconstructed quarterly it is an afternoon of archaeology.
Share this post
Keep reading
Conventional Commits for a Small Team
A prefix on every commit message - feat, fix, chore - makes the log scannable and the changelog half-written. Keep the rules short or the team routes around them.
Release Notes People Actually Read
A changelog generated from commits is a ledger; release notes are a letter to your users. Who you are writing for changes what you write - and what you leave out.
Deploying a Laravel App With Git Push
A bare repo and a post-receive hook are enough for a honest small-team deploy: checkout, composer, migrate, cache.
