How to turn GitHub commits into posts people actually read
By Naod Tadele · · 6 min read
Your commit history is the most honest record of what you built this week. It's also almost unreadable to anyone who isn't you.
"feat: add debounce to search input" is a good commit message. As a post, nobody cares. The work behind it might matter a lot to your users, but the message describes the code, not the change in their day.
Turning commits into posts is a translation job. Here's how to do it.
Step 1: Pick the commits worth talking about
Most commits aren't posts. Dependency bumps, refactors, CI fixes and typo corrections are real work, but they don't change anything a user can see. Skip them.
Look for commits that:
- Change what a user can do (a new feature, a new option)
- Remove a pain (a bug people hit, something slow that's now fast)
- Took a real decision (you chose one approach over another)
- Came from a user request
Usually that's one to three commits out of a week's work. That's plenty.
Step 2: Group related commits into one story
Features rarely ship in one commit. If five commits this week all touched search, that's one post about search, not five posts.
A useful test: if you described the week to a friend, what would the headlines be? Each headline is a post. The commits are the evidence.
Step 3: Translate from code to consequence
This is the step that matters. For each story, answer: what can someone do now that they couldn't before?
Before
feat: debounce search input, add fuzzy matching, cache recent queries
After
Search in Nightshift now forgives typos and remembers what you looked for last. Type "databse" and you'll still find the database alerts.
The second version mentions the product, describes the user's experience, and gives one concrete example. It's also shorter than the commit list.
Step 4: Add the why, if there is one
The best posts carry a small story. Why did you build this now? Who asked? What did you try first?
Three people emailed this month saying search "didn't work". It did work. It just didn't forgive typos. Fixed that. Search now matches "databse" to "database".
Step 5: Keep numbers real
If you mention numbers, use the actual ones from the commit or PR: lines changed, files touched, how much faster a page loads. Never round up or invent a number to sound impressive. Followers who are developers can tell.
Common mistakes
- Posting the changelog. A bullet list of commit messages reads like release notes, and release notes don't get read.
- Hiding the product. Name what you're building. People can't follow what they can't name.
- Over-explaining the implementation. One sentence of "how" is interesting to developers. A paragraph loses everyone else.
- One post per commit. You'll run out of patience before your audience runs out of scrolling. Group them.
A faster way
If you do this every week, the pattern gets repetitive: scan commits, skip the noise, group the rest, translate, write. That's exactly what Loudcode automates. You pick the commits you want to talk about, and it writes one post that ties them into a single story, using your product's description so it explains why the change matters. You edit and approve every post before it goes out.
Want more material than commits? Here are 30 build in public post ideas for the weeks between features.