Hey everyone, I was pairing with a new team member yesterday and realized my usual advice of "just ask the AI to match our commit style" wasn't really cutting it. It kept giving us something generic. Then it hit me: we can give it the *actual data*.
Instead of trying to describe our conventions, I just piped the git log directly into the prompt. The results were immediately better. Here’s the quick recipe I used:
```bash
# Get the last 50 commit messages, just the summary
git log --oneline -50 | pbcopy
```
Then, in my AI assistant (this works in Claude, ChatGPT, etc.), my prompt looked like this:
```
I'm writing commit messages. Please follow the style and conventions shown in these examples from my team's repository:
New change: Refactored the Lambda function cost tagging to use resource tags instead of a DynamoDB lookup. This includes the Lambda code and the Terraform module.
```
It generated a perfect commit message following our exact patterns—like using a specific prefix for cost-related changes and keeping the summary under 72 chars. No more back-and-forth.
This is a game-changer for onboarding. You can create a shared team note with this command and a base prompt, so everyone’s AI assistant learns the same style. It’s like a quick, automated style guide for commits, PR descriptions, or even code comments if you pipe relevant code snippets.
Thinking about trying this with `git diff` for code review feedback patterns next. Has anyone else experimented with feeding raw git history into their prompts for other tasks?
cost first, then scale
You're feeding proprietary code history into a third-party AI. That's a compliance and data leak waiting to happen. Does your company not have a policy about this?
The cost of a security review after a breach is a lot higher than teaching someone your commit style manually.
show me the bill
You're absolutely right about the risk, and it's something my team debated when we first tried this. We ended up using a self-hosted model runner for anything with real logs.
But for public or open-source repos, the technique itself is still pretty neat. It's about moving from vague instructions to concrete examples, which is a good pattern. The real problem is where those examples come from.
Pipeline Pilot
Self-hosting is good, but now you've just shifted the problem. The cost of running your own model infra for every team to "train" on their own logs is ridiculous. Most places will skip the security review on that too, it's just hidden now.
Real issue is needing AI to write commits at all. If your style is so complex it requires a model, your process is the problem.
ticket closed at 0400
Your technique highlights a critical shift in how we can train AI on specific data patterns, and you're right that concrete examples outperform vague instructions.
The immediate compliance red flag, however, is the implicit assumption that all 50 of those commit messages are safe to export. Commit histories routinely contain sensitive data: internal ticket numbers, pre-release feature names, security bug references, or even accidental secrets in the summary line. Piping them to a third-party service without a sanitization step is a data classification failure.
A safer middle ground for teams without self-hosted models would be to use this method locally with an open-source model via Ollama or the OpenAI API, where you can explicitly set data retention to zero and process everything offline. That at least contains the blast radius to your own infrastructure.
The real value here is the pattern-recognition for style, which is excellent, but the operational security of the delivery mechanism is often an afterthought.
trust but verify
You've nailed the hidden danger I wouldn't have thought of. At my old company, we definitely used internal Jira ticket keys in commit messages all the time. Piping that log would expose our entire project naming scheme and workflow.
I like your point about using this as a pattern-recognition tool. It makes me wonder if there's a simple, safe way to *generate* synthetic training examples instead. Like, could you ask the local model to "analyze this style and produce 10 clean, safe example messages that match it" and then use *those* in your cloud prompts?