Can I automatically post to LinkedIn from GitHub?

Yes, but the hard part is not the posting, it is the writing. A webhook can push a commit message to LinkedIn in an afternoon, and the result reads like a robot talking to other robots. The work is turning a commit like 'fix: null check on user.email' into a sentence a human would want to read.

What should I post about if I only pushed small fixes this week?

Often nothing. A week of small internal fixes is a week with nothing worth saying, and posting anyway trains people to skip you. The discipline is not finding an angle on every week. It is knowing which weeks to skip.

Do I need to write conventional commits for this to work?

No. Conventional commits help a machine group your work, but ordinary messy commit messages carry the same information. If you are only adopting a commit convention so you can market yourself, you have added a chore to avoid a chore.

How to turn GitHub commits into LinkedIn posts

You shipped all week. On Friday, someone asks what you have been up to, and you say "stuff". Meanwhile the person who shipped nothing has posted four times and everyone thinks they are winning.

Here is the thing you already know: the record of what you built is sitting in your commit history. Complete, accurate, timestamped, and written by you. You do not need to remember what you shipped. You need to translate it.

This post covers how to do that by hand, why that stops working, and what to do instead.

Your commit log is already the first draft

Start here, in any repository you have been working in:

git log --since="1 week ago" --pretty=format:"%h %s" --no-merges

That gives you something like this:

9f2c1a feat: add CSV export to dashboards
3b7d84 fix: logout now ends the session
c41e07 feat: magic-link sign-in
a18e55 chore: bump deps
7d2b91 refactor: extract billing client

That is your week. Five lines, and two of them are things a stranger would care about.

This is the part people get wrong. They look at that list and try to post all of it, or they look at it and conclude none of it is interesting. Both are wrong. The list contains a small number of things that changed for the person using your product, and a larger number of things that only changed for you.

Separate what changed for them from what changed for you

Go line by line and ask one question: did this change what a user can do?

Commit	Changed for a user?	Post-worthy
`feat: add CSV export to dashboards`	Yes, they can export now	Yes
`fix: logout now ends the session`	Yes, a real bug they hit	Yes
`feat: magic-link sign-in`	Yes, a new way in	Yes
`chore: bump deps`	No	No
`refactor: extract billing client`	No	No

The refactor was probably the hardest thing you did all week. It is still not a post. Nobody outside your codebase has any way to care that the billing client is now its own module, and pretending otherwise is how build-in-public posts start sounding like filler.

Three commits survived. That is a good week.

Write the claim, not the commit

Now translate each surviving commit into a sentence about what someone can now do. The commit is written from inside the code. The post has to be written from outside it.

The rule that keeps this honest: every sentence in the post must trace back to a specific commit. If you cannot point at the hash it came from, delete the sentence. That one rule is what separates a build-in-public post from marketing copy, and readers can feel the difference even when they cannot articulate it.

So:

feat: add CSV export to dashboards becomes "You can now export any dashboard to CSV."
fix: logout now ends the session becomes "Logging out actually ends your session now. It did not before, which is embarrassing, and it is fixed."
feat: magic-link sign-in becomes "Magic-link sign-in is live. No password to forget."

Notice what did not happen. No "excited to announce". No "thrilled to share". No claim that any of this is revolutionary. You shipped three things, you said you shipped three things, and the specificity is what makes it credible. "We shipped CSV export" is believable in a way that "we are transforming how teams work with data" never will be.

The fix is the most valuable one, and most people cut it. Admitting that logout was broken costs you nothing and buys you enormous credibility, because everyone reading has shipped that bug too.

Then assemble the post

Stack the claims, add one line of context at the top, and stop.

Shipped this week:

- You can now export any dashboard to CSV.
- Logging out actually ends your session. It did not before. That is fixed.
- Magic-link sign-in is live, so there is no password to forget.

The logout bug had been there for two months. Nobody reported it.
That is the part that bothers me.

That post takes ten minutes to write and it is better than most of what is on LinkedIn, because it is true, specific, and it admits something.

Why this stops working

You now have a repeatable process. You will do it for three weeks.

Then you will ship something hard on a Thursday, be exhausted on Friday, and skip it. Then you will skip the next one, because you skipped the last one and posting again feels like starting over. Two months later you have a dead feed and a vague sense of guilt.

This is not a discipline problem, and treating it as one is why the advice to "just be consistent" never helps anybody. The problem is structural. The task requires you to switch out of the mode where you build and into the mode where you market, every single week, forever, using a completely different part of your brain, at the exact moment you have the least energy left. Of course it decays.

The obvious response is to automate it, and the obvious automation is wrong. A webhook that pipes commit messages into LinkedIn takes an afternoon to build and produces exactly what you would expect:

New commit: fix: null check on user.email

Nobody wants that. The posting was never the hard part. The translation is the hard part, and it is the only part that matters.

What actually has to be automated

For this to work without you, a tool has to do the three things you were doing by hand:

Read what you shipped. From the commit history, so it is grounded in fact rather than in what you can remember on a Friday.
Throw most of it away. Decide which commits changed something for a user and which only changed something for you. A dependency bump is not a post.
Know when to say nothing. This is the one everybody skips. Some weeks you shipped nothing worth mentioning. A tool that posts anyway will invent a milestone to fill the slot, and inventing milestones is worse than silence.

That third one is the whole game. Any tool that must produce output on a schedule will eventually fabricate, because the schedule does not care whether you shipped. And the moment your audience catches one invented claim, every true thing you ever posted becomes suspect.

That is what PeerPost does. You connect a repository, keep shipping exactly as you do now, and posts arrive grounded in your real commits, with nothing invented. On a quiet stretch it writes nothing, on purpose. If you want the specifics of the GitHub side, we wrote them up on the GitHub to LinkedIn page. If your code is on GitLab, that works too.

Until then, run the git log command at the top of this post on Friday. It takes ten minutes and it beats saying "stuff".