How to Turn Your GitHub Pull Requests into LinkedIn Content

Every developer merges pull requests weekly. Most never talk about them publicly. That’s a missed opportunity.

Your PRs contain stories — problems solved, decisions made, trade-offs weighed. LinkedIn’s audience loves this kind of content. Here’s how to turn your GitHub activity into a consistent content stream.

Why PRs make great LinkedIn content

A pull request is a complete narrative: there was a problem, you explored solutions, you made decisions, and you shipped a result. That’s the exact structure of an engaging LinkedIn post.

Compare these two approaches:

Bad: “Just pushed some code updates to our app.”

Good: “Our API response times were hitting 800ms. Unacceptable. After profiling, I found we were making 12 sequential database queries per request. Rewrote it to 2 batched queries. Result: 50ms response times. Here’s what I learned about query optimization in Go…”

The second post tells a story. It has conflict, a journey, and a resolution. And all that information was already in the PR description.

What to extract from a PR

Not every PR is post-worthy. Focus on these types:

Feature launches

Any user-facing feature is worth posting about. Focus on the why, not the what.

• Why did you build this feature?
• What problem does it solve for users?
• What was the hardest part?

Performance improvements

Numbers are LinkedIn gold. If you improved something measurable, post about it.

• What was the before/after?
• How did you identify the bottleneck?
• What technique did you use?

Refactoring and tech debt

Developers relate to this deeply. Everyone has tech debt stories.

• What was broken or ugly?
• Why did you finally fix it?
• What did you learn about code maintenance?

Bug fixes (the interesting ones)

The weirder the bug, the better the post.

• What was the symptom?
• How did you track it down?
• What was the root cause?

The PR-to-post framework

Here’s a simple template:

1. Hook (1 line): The problem or result, stated dramatically
2. Context (2-3 lines): What you were working on and why
3. Journey (3-5 lines): What you tried, what failed, what worked
4. Result (1-2 lines): The measurable outcome
5. Takeaway (1-2 lines): The lesson others can apply
6. Question (1 line): Invite engagement

Example transformation

PR title: “Migrate auth from JWT to session tokens”

PR description: “Switched from stateless JWT to server-side sessions stored in Redis. JWTs were causing issues with token revocation — when a user changed their password, old tokens remained valid for up to 7 days. Sessions give us instant revocation.”

LinkedIn post:

We just ripped out our entire auth system and rebuilt it from scratch.

For the past year, we used JWTs for authentication. Stateless, simple, by the book. But we hit a critical problem: when a user changed their password, their old tokens stayed valid for up to 7 days.

That’s not a security model. That’s a liability.

We migrated to server-side sessions backed by Redis. The tradeoff? We now need a Redis lookup on every request. But session revocation is instant, and Redis handles 100k+ lookups/second without breaking a sweat.

The migration took 3 days for 2,000+ active users. Zero downtime. Zero complaints.

Sometimes the “old school” approach is the right one. What auth strategy are you using? #buildinpublic #webdev

Automate the process

Writing a post from a PR takes 15-20 minutes if you do it manually. Or you can automate it.

ShipPost watches your GitHub repos for merged pull requests and automatically generates LinkedIn post drafts. It reads the PR title, description, and metadata, then creates a post in your writing voice. You review, edit if needed, and publish.

No more “I should post about this” followed by forgetting about it entirely.

Start with your last 5 PRs

Go to your GitHub profile right now. Look at your last 5 merged PRs. At least 2 of them have a LinkedIn post hiding inside. Pick one and write about it today.

The developers who grow their audience aren’t necessarily the ones doing the most impressive work. They’re the ones who talk about their work consistently.