Mortdecai
ea3cf45953
The original repo presented everything as equal rules. In reality, the workflow has two tiers: core practices (used in every project) and advanced rules (only in complex projects like Mortdecai). Core tier adds: - backup-before-edit (global CLAUDE.md rule) - superpowers-workflow (the actual workflow engine) - memory-system (persistent feedback and project memories) - document-hierarchy (CLAUDE.md/SESSION.md/CONTEXT.md/IDEA.md) - commit-and-push discipline - feedback-driven behaviors Updated README, docs, and dynamic-methodology to reflect the two-tier reality instead of presenting advanced rules as universal. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
74 lines
2.5 KiB
Markdown
74 lines
2.5 KiB
Markdown
# Commit & Push Discipline
|
|
|
|
The actual commit workflow: commit every meaningful change immediately, push on the same command. No squashing, no batching unrelated changes.
|
|
|
|
## The Rule
|
|
|
|
**Commit and push after every meaningful change.** Not at the end of the day. Not in batches. Every completed function, bug fix, test addition, or documentation update gets its own commit and push.
|
|
|
|
## Why This Is Non-Negotiable
|
|
|
|
1. **You never lose more than 15-30 minutes of work.** If the machine dies, the power goes out, or the AI assistant corrupts a file, your latest work is already on the remote.
|
|
2. **Fine-grained history.** Each commit is one logical change. `git bisect` actually works. Reverts are surgical, not radioactive.
|
|
3. **No merge conflicts from batching.** Small, frequent pushes rarely conflict. Large, infrequent pushes always do.
|
|
4. **Accountability.** The commit message explains *what* and *why* for each change individually.
|
|
|
|
## Commit Message Format
|
|
|
|
Conventional commits, always:
|
|
|
|
```
|
|
<type>: <short description>
|
|
```
|
|
|
|
| Type | When |
|
|
|------|------|
|
|
| `feat:` | New feature or functionality |
|
|
| `fix:` | Bug fix |
|
|
| `docs:` | Documentation changes |
|
|
| `refactor:` | Code restructuring (no behavior change) |
|
|
| `test:` | Adding or updating tests |
|
|
| `chore:` | Maintenance, dependencies |
|
|
|
|
Examples:
|
|
```bash
|
|
git commit -m "feat: add user authentication endpoint"
|
|
git commit -m "fix: resolve null pointer in data parser"
|
|
git commit -m "test: add unit tests for payment module"
|
|
```
|
|
|
|
## Push Immediately
|
|
|
|
After committing, push in the same command or immediately after:
|
|
|
|
```bash
|
|
git add <files> && git commit -m "feat: ..." && git push
|
|
```
|
|
|
|
If using a git hosting CLI wrapper (like `gitea push`), use that — it handles authentication automatically.
|
|
|
|
## What Counts as "Meaningful"
|
|
|
|
- A function completed and working
|
|
- A bug fixed and tested
|
|
- Tests added or modified
|
|
- Documentation updated
|
|
- Configuration changed
|
|
- Before switching to a different task
|
|
- Before risky experiments
|
|
- Every 15-30 minutes of active coding (at natural breakpoints)
|
|
|
|
## What Does NOT Get Committed
|
|
|
|
- Code that doesn't compile or run
|
|
- Half-finished features with no clean boundary
|
|
- Files containing secrets (.env, credentials, tokens)
|
|
- Temporary debugging artifacts (console.log spam, print statements)
|
|
|
|
## Security Before Committing
|
|
|
|
Before every push:
|
|
- Ensure `.env` and credential files are in `.gitignore`
|
|
- The pre-push hook (if installed) scans tracked files against known secret values
|
|
- Never commit secrets — if one slips through, rotate immediately (git rm doesn't erase history)
|