I Stopped Manually Committing – Here’s Why

I don’t code much in my day job anymore, but I still love building things. So last weekend, I finaly took the time to test GitHub Copilot’s Agents feature — specifically, a Commit Agent. I’ve seen agents.md and knew the theory, but I wanted the live experience: Could this actually improve my workflow, or was it just another layer of automation hype?

Even when working alone, I sometimes need to revert—and that’s when I really appreciate clean, atomic commits. But let’s be honest: I’m not always disciplined enough to enforce that myself. So I figured, why not seek the help of an agent?

I set up a commit.agent.md to check for the things I should already be doing (or what I’d demand from anyone committing to my project):

Commits should be

• small (no mass commits, spanning the whole repo)
• one issue per commit, not fixing / changing multiple issues at once
• describe the change properly in the message
• check if the commit also requires adjusting my specification /readme
• …

Before searching for a good commit agent on GitHub, I asked GHC to create an agent for me and modified it only slightly manually. The rest looked pretty well for a test. (I stripped some lines for readability).

---
name: Commit
description: Pre-commit review and commit message generation
---

# Commit Agent

You are a pre-commit assistant for a plain PHP 8+ application. Review staged changes and help create proper commits.

## Pre-Commit Checklist

When asked to review or commit, analyze the staged changes and check:

### 1. Documentation Updates
- [ ] README.md updated if setup/usage changed
- [ ] Code comments added for complex logic

### 2. Schema & Config Changes
- [ ] **WARNING** if database schema changes detected (new tables, columns)
...

### 3. Breaking Changes
- [ ] **WARNING** if API endpoints changed (routes, parameters, responses)
- [ ] **WARNING** if frontend JavaScript depends on changed backend

### 4. Security Review
...

### 5. Code Quality
- [ ] PSR-12 style followed
- [ ] No debug code left (var_dump, console.log)
...

### 6. Commit Size
- [ ] **WARNING** if more than 5 files changed - consider splitting into smaller commits
- [ ] **WARNING** if changes span multiple unrelated features/fixes
- [ ] **WARNING** if total lines changed > 200 - may be too large for easy review

Good commit examples:
...

Bad commit examples:
...

## Output Format

```
## Pre-Commit Review

### Changes Summary
- Brief description of what changed

### Commit Size
✅ X files changed - OK
OR
⚠️ X files changed - Consider splitting this commit

### Warnings
⚠️ List any warnings (schema changes, breaking changes, etc.)

### Security
✅ No issues found
OR
❌ Issue: description

### Suggested Commit Message
```
Short summary (50 chars max)

- Bullet point details
- Another detail
```

### Ready to Commit?
✅ Yes, looks good
OR
❌ No, please address: [issues]
```

## Commands

When user says:
- `@commit review` - Review staged changes, don't commit
- `@commit` - Review and suggest commit message
- `@commit "message"` - Review and commit with provided message

Being honest to myself, I guess I wouldn’t have been so strickt to myself usually, but hey … I asked for a virtual reviewer, now I got one!

That said, I started coding and really tried to commit after every change – knowing that the robot-reviewer might not show any mercy to me! In order to commit, I just typed @commit into the GHC chat and often got a good review and confirmation like

Pre-Commit Review
Changes Summary
Added commit size guidelines to commit.agent.md (warning thresholds for file count, line count, and single-responsibility principle)
Commit Size
✅ 1 file changed, 19 lines - OK

Warnings
None

Security
✅ No code changes - documentation only

Suggested Commit Message

Added general documentation

Ready to Commit?
✅ Yes, looks good

Phew, lucky me!

But would it catch me doing too much at once? I tested it by bundling two unrelated changes — translating the registration page and switching the color scheme — into a single commit. Sure, it were just tiny things in one file, but let’s see, @commit …

Suggested Commit Messages
Option A (combined):

Translate registration page to German and use grayscale colors

Option B (split - recommended):

Commit 1: "Translate registration page to German"
Commit 2: "Use grayscale color scheme on registration page"

Okay, I admit, the two changes are probably really unrelated.

During the programming session I found myself almost never doing a classical git commit but nearly always doing an @commit and check if I was violating my own rules.

But what was the effect of the whole exercise?

My git history became cleaner, my commit messages more descriptive, and — most importantly — I actually trusted my own logs. This also reduces the risk of those ‘WTF was I thinking?’ months later when I need to revert to some stage. The agent didn’t just enforce rules; it made me think like a better collaborator — even when working alone.

The TL;DR: The agent forced me to follow best practices. Result: Cleaner code, clearer history, and no more ‘WTF was I thinking?’ later.

I must admit … It feels better! Right now I might even say: I hope that I won’t do a git commit myself again in the near future!