34 lines
1.2 KiB
Markdown
34 lines
1.2 KiB
Markdown
# Contributing
|
|
|
|
## Branching Rule
|
|
- Direct pushes to `master` are forbidden.
|
|
- Every task must be implemented in a separate branch.
|
|
- Finished work must be delivered through a merge request into `master`.
|
|
|
|
## Standard Flow
|
|
1. Update local `master`.
|
|
2. Create a task branch from `master`.
|
|
3. Implement the change in that branch.
|
|
4. Run the relevant verification for the change.
|
|
5. Commit the work in that branch.
|
|
6. Push the branch to Gitea.
|
|
7. Open a merge request into `master`.
|
|
8. Merge only after review or explicit approval.
|
|
|
|
## Branch Naming
|
|
Use short, purpose-driven names, for example:
|
|
- `feature/auth-password-reset`
|
|
- `fix/session-revoke`
|
|
- `docs/deployment-notes`
|
|
- `chore/gitignore`
|
|
|
|
## Minimum Expectations
|
|
- Keep changes scoped to one task per branch.
|
|
- Do not mix unrelated refactors into the same merge request.
|
|
- Update docs when behavior, deployment, or operational flow changes.
|
|
- If schema changes are introduced, include the Prisma migration in the same branch.
|
|
|
|
## Agent Workflow
|
|
- Codex or any other coding agent must create and use a dedicated branch per task.
|
|
- After task completion, the agent should push that branch and prepare it for a merge request instead of pushing directly to `master`.
|