Show HN: Build the habit of writing meaningful commit messages
Mood
informative
Sentiment
positive
Category
startup_launch
Key topics
Commit Messages
Ai Assisted Development
Productivity Tools
So why don't i get AI to help me get that into words from my head?
That's what i built: smartcommit asks you questions about your changes, then helps you articulate what you already know into a proper commit message. Captures the what, how, and why.
Built this after repeatedly being confused 6 months in a project as to why i made the change i had made...
Would love feedback!
Discussion Activity
Moderate engagementFirst comment
3h
Peak period
6
Hour 17
Avg / period
2.8
Based on 44 loaded comments
Key moments
- 01Story posted
Nov 22, 2025 at 3:54 PM EST
1d ago
Step 01 - 02First comment
Nov 22, 2025 at 7:11 PM EST
3h after posting
Step 02 - 03Peak activity
6 comments in Hour 17
Hottest window of the conversation
Step 03 - 04Latest activity
Nov 23, 2025 at 6:46 PM EST
8h ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
https://google.github.io/eng-practices/review/developer/cl-d...
https://zulip.readthedocs.io/en/latest/contributing/commit-d...
Almost daily, I use commit messages and history as part of understanding why a decision was made, why a seemingly obvious alternative wasn’t chosen, etc. seeing the commit title on every line, and hovering to see the full message has become a core editor feature for me.
It’s kind of like testing, the more I do it, the more I want to do it because the value is so consistently reinforced.
There’s nothing like being able to track down exactly why a decision was made 6 years ago in a part of the code base you are struggling to understand written by someone who left before you joined the team.
I don't understand why so many engineers are like this.
The other issue with tagging JIRA tickets is that junior developers will believe that to be enough (you can just read the ticket) and wont understand why they need to describe the change from a technical angle, when it's already described in JIRA.
To fail to do so is a gigantic missed opportunity in my opinion. You never know when you will need it.
Similarly with AI it is fairly simple to have eg a pre-merge check that validates the commit msg is somewhat useful. This could be implemented for example with GitHub org level checks that must run in a PR.
Honest to God, this would discourage frequent commits.
Which will lead to a lot of work not being committed.
Thoughtful messages are for PRs.
(On a good day, that is. Though even on a bad day I don't let "wip" commits into the main branch.)
You don’t need 98% of commit messages ever again.
Yes when you need those 2% most likely it is for important reasons but usually not so important to make all the other mulled over.
If you make a change to your codebase, normally you know what you want to achieve and why (otherwise... what are you even doing?). A commit message is just putting that in writing... that only takes a few seconds, often less than it takes to write the code.
So it's just a good habit to have. It forces you to think more about the changes you do & why, so it makes you a better software developer. Creating any new habit always takes some energy initially, but it's worth it.
If we work together for years it makes sense to cooperate.
Unfortunately most IT projects are you do it for 2 years and then you will never ever work on it again.
but in practice it's not a huge problem, IDE shows you the commit history of a specific file so bisecting changes is easy, there's only a few entries with the roughly correct date modifying the file you're looking for :D
"low quality code/commit messages" hasn't really slowed me down so far and probably won't in the future either
Asking people to fit a meaningful description of the change into 50 characters is silly, and it's IMO the reason why so many of them just write "fix bug" and call it a day.
Someone else has posted the Google guide for CL (change list) messages, but let me boost the signal: https://google.github.io/eng-practices/review/developer/cl-d...
This is, I believe, still the best guide out there. When I'm coaching juniors, I recommend this guide, over the opinionated and outdated git "best practices" and I think the results are much better.
If a commit is sufficiently complex the long form could be 600 characters and the short form 200.
Can you give me an example of a commit where the "short, focused summary" can only be usefully-expressed in 200+ characters?
Notably, all of the "good" examples in https://google.github.io/eng-practices/review/developer/cl-d... have first lines under 72 characters.
Restrictions lead devs to write to useless messages like 'fixed a bug' rather than messages that are slightly verbose but actually useful.
Most messages wont be 200 chars. But id rather 200 chars of useful text than 72chars of useless text.
The real world is full of average devs that are average writers under time pressure to deliver code. Expecting them to deliver above average commit messages like googles examples is a pipe dream.
I think they should be (or at least "decent").
Should this reasoning be applied to other skills involved in software engineering? If someone never writes tests, or over-architects everything, or has terrible people skills, or never updates documentation, or doesn't bring attention to blockers, or constantly forgets to update the issue tracker, or doesn't follow the local code conventions, or works on random tasks and ignores high-priority ones, etc etc etc the solution isn't usually "don't ask them to do a thing they're bad at", it's "help them get better".
The important question is whether "skimmable commit messages" is a thing you care about enough to advocate for and teach people about. Maybe you don't, and that's fine.
> But id rather 200 chars of useful text than 72chars of useless text.
I completely agree with this. I just don't think those are the only two options.
> Expecting them to deliver above average commit messages like googles examples is a pipe dream.
This thread started with praise for that Google guide and I assumed you were of similar opinion given your reply. That's why I kept referring to it.
It baffles me how people think git log reading like a novella is a good idea. It’s not, because a cherrypick or merge can/will/should overwrite whatever clever garbage you put in there with its own message. Are you going to summarize Q4’s battle with scaling in a paragraph on the sprint merge to master? No. No you aren’t.
So, while I’m against commit messages saying “fixed”, obviously, I’m equally against a “conversation” in git.
If you have engineers on your team that are anal about commit messages, ask them to be as anal about features and teach them to git diff.
I like putting a minimal description in the message itself too so it's easier to skim the log, though.
Obligatory "show me the prompt" https://news.ycombinator.com/item?id=39374249
That might indicate an underlying problem that can’t be fixed with AI. ;)
This was a delayed project running out of budget and everything had to be completed within a few months. However, the management in it's infinite wisdom also did a complete source code/issue management platform change.
The person who did the repo migration went with the default settings. (I believe this was the case. I forget the details. I would also only half blame the person because everything was rushed)
Everything up to that point was committed with "Made by so and so bot".
This was way ahead of Google was allegedly committing "well over 30%" of code by AI. I witnessed the true pioneers in this space.
> For the love of clean code history, let's remember we're not monkeys banging on keyboards; we're educated, civilized human beings.
This has nothing to do with self-documenting code. On the contrary, in fact, if I have to resort to checking git history that means the code is not self documenting.
From that description I thought it was going to generate the message directly from the diff and the message not being what you thought it would be would be a signal that the code isn't self documenting.
The act of composing a descriptive and concise commit message compels the programmer to transition from the task of "path-making" (writing code) to the intellectual work of explaining the process, which is necessary to grok the change completely.
Reviving the theory of an existing program is a difficult, cult-frustrating, and time-consuming effort. When theory-building is neglected, we lose the intellectual foundation that dictates the program's purpose and design, trapping future maintenance efforts in a costly, confusing cycle of trying to deduce intent from artifact alone
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.