25 lines
1.3 KiB
Markdown
25 lines
1.3 KiB
Markdown
# 02 — Branching/Release — Plan (LLM)
|
|
|
|
- Model: Trunk-based with protected `main` (always green, production-ready) + short-lived feature branches (`feat/*`, `fix/*`, `chore/*`, `docs/*`, `ci/*`, `refactor/*`). Optional `next` integration branch only if batching risky work.
|
|
- Repo content on `main`: Full repo (code, prompts, templates, docs) — must pass CI and audits on every merge.
|
|
- Tags: `YYYY-MM-DD-HHMM` on release-ready commits.
|
|
- CI protections: Required checks (audit + Docker tests), linear history, PR required, Conventional Commits.
|
|
|
|
- Migration steps:
|
|
1) Tag current good baseline (e.g., `YYYY-MM-DD-HHMM`).
|
|
2) Create `wip/phase1` branch from current `main`; continue all WIP there under PRs to `main`.
|
|
3) Enable protections on `main` in Gitea: required checks (audit/test), PR reviews, linear history.
|
|
4) Document policy in `docs/branching.md` and update README.
|
|
5) Add templates/docs for downstream projects to adopt same policy (if needed).
|
|
|
|
- Acceptance:
|
|
- `main` protected with required CI checks; PR required; Conventional Commits enforced.
|
|
- `wip/phase1` exists; ongoing work targets it.
|
|
- Tags used only for release-ready commits on `main`.
|
|
- `docs/branching.md` present and referenced by README.
|
|
|
|
- Notes:
|
|
- Reassess `next` only if multiple parallel risky features emerge.
|
|
- Keep branches short-lived; delete after merge.
|
|
|