DEV Community

Cover image for I Stopped Writing Commit Messages. Here's What I Do Instead.
PADMANABHA DAS
PADMANABHA DAS

Posted on

I Stopped Writing Commit Messages. Here's What I Do Instead.

#github #productivity #ai #beginners

I have a confession: I'm terrible at writing commit messages.

Not the commits themselves — I know what I changed. But turning "fixed that thing where the button didn't work on mobile" into a proper fix: resolve touch event handler on mobile viewport while I'm in the zone? That's where I fall apart.

And PR descriptions? Forget it. By the time I've made 15 commits across three days, I can barely remember what the first five were about.

So I built a tool to do it for me.

The Problem No One Talks About

Here's my typical workflow before I automated this:

  1. Make changes
  2. git add .
  3. Stare at terminal for 30 seconds, trying to remember what I just did
  4. Write something vague like update stuff
  5. Repeat 12 times
  6. Open PR
  7. Spend 20 minutes scrolling through commits to write a description
  8. Give up and write "various fixes and improvements"

Sound familiar?

The thing is, I know what good commit messages look like. I just don't have the mental energy to write them while I'm deep in code. Context switching from "solving a problem" to "documenting a solution" is exhausting.

What I Actually Built

I created a GitHub MCP server — 44+ tools that let Claude interact directly with my repositories. But honestly? I use maybe 5 of them regularly. And they all revolve around one thing: making Claude do the boring parts of version control.

Here's my actual workflow now:

Workflow 1: "What Did I Even Do?"

After making changes but before committing, I ask Claude:

"Check my uncommitted changes and suggest a commit message. Use conventional commits format"

Claude uses the file system tools to scan my changes, looks at what files were modified, reads the diffs, and comes back with something like:

feat(auth): implement refresh token rotation with 7-day expiry

- Add token rotation logic in authMiddleware
- Update User model with refreshTokenFamily field
Enter fullscreen mode Exit fullscreen mode

That's better than anything I would've written at 11 PM.

Workflow 2: "Summarize My Last Week"

This is the one I use before creating PRs. Let's say I'm on a feature branch with a bunch of commits, and I need to open a PR against master

I ask Claude:

"Using my GitHub MCP tools, list all commits on feature/user-dashboard that aren't on master. Analyze what changed across all of them, then give me a PR title, description, and suggested labels"

Here's what happens behind the scenes:

Step 1: Claude calls list-commits on the feature branch:

// Tool: list-commits
{
  owner: "chayan-1906",
  repository: "PulsePress",
  branch: "feature/user-dashboard",
  perPage: 30,
  currentPage: 1,
}
Enter fullscreen mode Exit fullscreen mode

Step 2: For each commit, Claude calls get-commit-modifications to see the actual file changes:

// Tool: get-commit-modifications
{
  owner: "chayan-1906",
  repository: "PulsePress",
  commitSha: "a1b2c3d..."
}
Enter fullscreen mode Exit fullscreen mode

This returns the filenames, additions, deletions, and even the patch diffs.

Step 3: Claude synthesizes everything and generates:

## PR Title
feat(dashboard): implement user analytics dashboard with real-time updates

## Description
This PR adds a comprehensive analytics dashboard for users to track their reading habits and content engagement.

### Changes
- New Components: AnalyticsChart, ReadingHistory, EngagementMetrics
- API Integration: Added endpoints for fetching user analytics data
- Real-time Updates: Implemented WebSocket connection for live stats
- Database: New analytics collection with aggregation pipelines

## Suggested Labels
feature, frontend, backend, needs-review
Enter fullscreen mode Exit fullscreen mode

Step 4: If I'm happy with it, Claude can even create the PR directly:

// Tool: create-pull-request
{
  owner: "chayan-1906",
  repository: "PulsePress",
  title: "feat(dashboard): implement user analytics dashboard with real-time updates",
  head: "feature/user-dashboard",
  base: "master",
  body: "..." // The generated description
}
Enter fullscreen mode Exit fullscreen mode

The Tools That Make This Work

Out of 44+ tools in my GitHub MCP server, here are the ones I actually use for this workflow:

Tool What It Does
list-commits Gets commits from a branch with pagination
get-commit-modifications Shows file changes for a specific commit (additions, deletions, patches)
list-branches Lists all branches when I forget my branch names
create-pull-request Creates the PR with title, body, head/base branches
list-pull-request-files Shows what files a PR touches (useful for reviewing my own PRs)

That's it. Five tools for 90% of my use case.

A Real Example

Last month, I worked on migrating my API from callback-based error handling to a centralized middleware approach. Seven commits over two days.

Here's what Claude generated after analyzing them:

## PR Title
refactor(api): migrate to centralized error handling middleware

## Description
Replaces scattered try-catch blocks with a unified error handling approach using Express middleware.

### Commits Analyzed
1. refactor: extract error types to dedicated module
2. feat: add ErrorHandler middleware
3. refactor: update auth routes to use new error handling
4. refactor: update user routes to use new error handling
5. refactor: update news routes to use new error handling
6. test: add error handling middleware tests
7. chore: remove deprecated error utility functions

### Impact
- Lines Changed: +245 / -312 (net reduction!)
- Files Modified: 14
- Breaking Changes: None (error response format unchanged)

## Suggested Labels
refactor, backend, tech-debt
Enter fullscreen mode Exit fullscreen mode

I would have written: "refactor error handling". Claude gave me context I'd already forgotten.

Why This Isn't Cheating

I used to feel guilty about this. Like I was exposing some weakness by not writing my own commit messages.

But here's the thing: the commits still contain all the information. Claude isn't making up what I did — it's reading my actual changes and summarizing them. The code is mine. The decisions are mine. The documentation is just... automated.

It's the same reason we use linters and formatters. I don't manually fix indentation — why should I manually write "moved function from line 45 to line 23"?

Setting It Up

If you want to try this yourself, the GitHub MCP server is open source:

Repository: github.com/chayan-1906/GitHub-MCP

Quick start:

  1. Download the executable for your OS from the releases page (https://github.com/chayan-1906/GitHub-MCP/releases)
  2. Run it once (it sets up Claude Desktop integration automatically)
  3. Start Claude and include "use available GitHub tools" in your prompts

The server runs locally and authenticates via GitHub OAuth. Your code never leaves your machine except through standard GitHub API calls.

What I'd Build Next

Honestly, this workflow has a gap: I can't analyze uncommitted changes through the GitHub API because... they're not on GitHub yet.

Right now, I use my File System MCP server for that part — it reads the local diff and suggests commit messages. But it would be cleaner to have a single tool that does both.

The Honest Takeaway

I'm not a better developer because I automated commit messages. I'm just a developer who recognized that "writing good documentation" and "writing good code" are two different skills — and I'm better at one than the other.

If you're like me — if you've ever written misc fixes or wip or asdfasdf as a commit message — maybe give this a try. Your future self (and your code reviewers) will thank you.

I write about AI tools I actually use. Find me on LinkedIn or check out my other projects on GitHub.

Top comments (0)