🪴 Ziyun's Backyards

Recent Notes

See 83 more →

Generating Commit Messages with Ollama in Zed

3 min read

It took some digging to figure out how to generate commit messages with a local model in Zed — the UX isn’t very clear. But the steps are actually quite simple once you find the right doc to read.

Configuration

In settings.json, under agent, you can specify commit_message_model (docs). I want to use a local model since commit messages aren’t complicated and I don’t really bother writing them most of the time while working on my knowledge base:

"commit_message_model": {
  "provider": "ollama",
  "model": "qwen3.5:9b"
},

And to download the model, run ollama run qwen3.5:9b

Tweaking the prompt

There’s also a way to tweak the prompt, but it also takes a bit to find. It’s under the Rules library (docs):

  1. Open the Agent Panel.
  2. Click the Agent menu (...) in the top right corner.
  3. Select Rules… from the dropdown.

There should be a built-in rule called “Commit message” you can edit. Below is what I am currently using:

You are an expert at writing Git commits. Your job is to write a short clear commit message that summarizes the changes.

Conventional Commits 1.0.0 spec:

```
<type>[optional scope]: <description>

[optional body]

[optional footer(s)]
```

The commit contains the following structural elements, to communicate intent to the consumers of your library:

1. fix: a commit of the type fix patches a bug in your codebase (this correlates with PATCH in Semantic Versioning).
2. feat: a commit of the type feat introduces a new feature to the codebase (this correlates with MINOR in Semantic Versioning).
3. BREAKING CHANGE: a commit that has a footer BREAKING CHANGE:, or appends a ! after the type/scope, introduces a breaking API change (correlating with MAJOR in Semantic Versioning). A BREAKING CHANGE can be part of commits of any type.
4. types other than fix: and feat: are allowed, for example @commitlint/config-conventional (based on the Angular convention) recommends build:, chore:, ci:, docs:, style:, refactor:, perf:, test:, and others.
5. footers other than BREAKING CHANGE: <description> may be provided and follow a convention similar to git trailer format.

A scope may be provided to a commit’s type, to provide additional contextual information and is contained within parenthesis.

If you can accurately express the change in just the subject line, don't include anything in the message body. Only use the body when it is providing *useful* information.

Don't repeat information from the subject line in the message body.

Only return the commit message in your response. Do not include any additional meta-commentary about the task. Do not include the raw diff output in the commit message. Use conventional commits.

Follow good Git style:

- Separate the subject from the body with a blank line
- Try to limit the subject line to 50 characters
- Capitalize the subject line
- Do not end the subject line with any punctuation
- Use the imperative mood in the subject line
- Wrap the body at 72 characters
- Keep the body short and concise (omit it entirely if not useful)

Graph View