1debffb22c
- replace IaC-specific wording with general, cross-project guidance - forbid runtime/incident/manual-ops narrative in commit message body - clarify commit messages describe repo changes, not behavior outcomes
89 lines
3.7 KiB
Markdown
89 lines
3.7 KiB
Markdown
# Git Instructions
|
|
|
|
## 🚨 GIT POLICY - ABSOLUTELY CRITICAL
|
|
|
|
**NEVER EVER make git commands without explicit user approval!**
|
|
|
|
### Forbidden Commands - DO NOT RUN:
|
|
1. ❌ **git add** - User runs this themselves (including git add ., git add -A, git add <file>)
|
|
2. ❌ **git commit** - User runs this themselves
|
|
3. ❌ **git push** - User runs this themselves
|
|
4. ❌ **git push --force** - User runs this themselves
|
|
5. ❌ **git reset** - User runs this themselves
|
|
6. ❌ **ANY command that modifies git repository or server state**
|
|
|
|
### What You CAN Do:
|
|
- ✅ `git status` - Show current state
|
|
- ✅ `git diff` - Show changes
|
|
- ✅ `git log` - Show history
|
|
- ✅ Show the command user should run
|
|
- ✅ Explain what the command will do
|
|
|
|
### Exception:
|
|
Only if user explicitly says:
|
|
- "commit this now"
|
|
- "push this now"
|
|
- "go ahead and commit"
|
|
|
|
Otherwise: **SHOW the command, WAIT for user to run it**
|
|
|
|
---
|
|
|
|
## Best Practices
|
|
|
|
- Always show `git diff` before suggesting commits
|
|
- Show `git status` to verify what will be committed
|
|
- Explain impact of each git operation
|
|
- User controls git commands, you analyze and advise
|
|
- Never assume user wants to commit
|
|
- Reliability over speed
|
|
|
|
---
|
|
|
|
## Commit Message Workflow
|
|
|
|
When the user asks for a commit message:
|
|
|
|
1. **Run `git diff --staged` or `git diff`** — read what actually changed
|
|
2. **Documentation check** — scan the changed files and ask: does any `docs/` or `README.md` need updating based on these changes? If yes, flag it clearly before writing the message. Do not block the commit — just surface it.
|
|
3. **Write the commit message only** — one short subject line, optionally a blank line and brief body if the change needs context. Output just the message text in a code block. Do NOT wrap it in a `git commit` command.
|
|
|
|
Format:
|
|
```
|
|
<type>: <what changed>
|
|
|
|
<optional: why, or what is not obvious from the diff>
|
|
```
|
|
|
|
Types: `feat`, `fix`, `docs`, `refactor`, `chore`
|
|
|
|
### Commit message rules
|
|
|
|
**Only include what actually changed in this commit.**
|
|
|
|
- Run `git diff --staged` (or `git diff` if nothing staged) and read it fully before writing
|
|
- List only files and lines that appear in the diff
|
|
- If a file appears in the diff but only has whitespace or comment changes, omit it from the body
|
|
- Never mention changes that are not in the diff — even if you remember discussing them earlier in the session
|
|
- If unsure whether something changed, check the diff — do not guess
|
|
|
|
**Format rules:**
|
|
- Subject line: max ~72 chars, imperative mood ("Fix", "Add", "Remove" — not "Fixed", "Added")
|
|
- Body: optional, only when the *why* is not obvious from the diff
|
|
- No bullet-pointed list of every file changed unless the diff spans many unrelated files
|
|
- No "CHANGES:" headers, no file-by-file breakdowns for single-topic commits
|
|
- No "Expected:", "Result:", "Impact:" or any speculative outcome sections — commit messages describe what changed, not what is predicted to happen
|
|
- Bullet points state *what* changed, not *why it was wrong* or *how it works* — keep each line short and factual
|
|
- ✅ `use MC_HOST_minio for S3 auth`
|
|
- ❌ `Use MC_HOST_minio env var for direct S3 auth (no mc alias set)`
|
|
- Do not describe runtime behavior, incident narrative, or manual operations in the commit message body
|
|
- ❌ `gitea failed on startup`
|
|
- ❌ `Redis services cleaned up manually`
|
|
- ❌ `Certificate renewed successfully`
|
|
- ✅ `disable redis sub-chart`
|
|
- ✅ `set queue type to level`
|
|
|
|
**All projects:**
|
|
- Treat commit messages as change logs of repository state, not behavior reports
|
|
- Never include runtime status, deployment outcomes, test run narratives, or manual operation confirmations unless the user explicitly asks for a release note or status report instead of a commit message
|