Prompting AI for Git Workflows, Commit Messages & PRs

Git history is documentation. Bad commit messages and shapeless pull requests slow your team down for years. AI can take the friction out of writing both — but only if you feed it the actual diff and your team's conventions.

1. Introduction

Most developers write commit messages and PR descriptions reluctantly, at the end of a long day, in two lines they will regret reading later. AI removes the cost of doing it properly: paste the diff, get a clear, conventional commit and a structured PR description in seconds. This tutorial walks through the patterns that work and the patterns that don't.

2. The Concept Explained

The only reliable input for AI when writing about a change is the change itself — the diff. Without it, the AI invents what you might have done. With it, the AI summarises what you actually did.

Think of the diff as the evidence and the AI as the writer. A good writer with the wrong evidence produces fiction; the same writer with the right evidence produces useful documentation.

3. The Problem Without This Technique

The classic mistake is asking for a commit message without showing the change.

write a commit message for my changes to the order endpoint

4. The Solution

Our team follows Conventional Commits. Allowed types:
  feat, fix, refactor, docs, test, chore, perf, style.
Scope is the affected module (e.g. orders, auth, ui).
Subject line ≤ 72 chars, imperative mood, no trailing period.
Body: explain the WHY in 1–3 short bullets when non-trivial.

Here is the staged diff:

```diff
diff --git a/src/routes/orders.ts b/src/routes/orders.ts
@@
-  if (req.body.quantity > 99) {
-    return res.status(400).json({ error: 'too many' });
-  }
+  const result = orderBodySchema.safeParse(req.body);
+  if (!result.success) {
+    return res.status(400).json({
+      error: { code: 'INVALID_BODY', message: result.error.message }
+    });
+  }
```

Write:
1. A commit message in our format.
2. A suggested branch name (kebab-case, prefixed with feat/, fix/, or
   refactor/ as appropriate).
3. A PR description with sections: Summary, Why, How, Test plan.

5. Step-by-Step Breakdown

1. Paste the diff, not a description. Use git diff --staged for commit messages, git diff main...HEAD for PR descriptions.
2. State the convention. Conventional Commits, Angular, Gitmoji, or your team's own format. Include the allowed types and any rules.
3. Cap the subject line length. 50 or 72 characters is standard. Without this, AI tends to write essays in the subject.
4. Ask for the why in the body. The diff already shows the what. Future readers need motivation, not narration.
5. Generate branch name and PR at the same time. Once the AI understands the change, all three artefacts come from the same context.
6. Review and edit. AI summaries can miss the real reason behind a change. You know the context the diff doesn't capture — add it.

Tip: For long-running PRs, regenerate the description from the cumulative diff before requesting review. It keeps the summary in sync with what the code actually became, not what it was two days ago.

6. Practice Exercises

7. Key Takeaways