# 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)