Jan Novak
91ac3b37cf
Feature work now goes on feat/<slug> branches; Claude pushes and prints the Gitea compare URL for the user to open the MR. Exceptions documented for small fixes and typo tweaks. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
84 lines
3.3 KiB
Markdown
84 lines
3.3 KiB
Markdown
# Branch-per-feature + Gitea MR workflow
|
|
|
|
## Context
|
|
|
|
Until now, Claude has been committing feature work directly to `main`
|
|
(see recent history: `feat: Lower adult monthly fee…`, `feat: Go rewrite M1…`,
|
|
all on `main`). The user wants to switch to a branch-per-feature flow with
|
|
review via a Gitea merge request, so that:
|
|
|
|
- Feature work is reviewable as a self-contained diff before it lands.
|
|
- `main` stays releasable.
|
|
- The change history shows reviewed merges, not unsupervised pushes.
|
|
|
|
The remote is Gitea (`https://gitea.home.hrajfrisbee.cz/kacerr/fuj-management.git`),
|
|
which supports the standard pull/merge-request flow.
|
|
|
|
This plan only modifies `CLAUDE.md`. No code changes.
|
|
|
|
## Scope clarification (from user)
|
|
|
|
- **MR creation method:** Claude pushes the branch and prints the Gitea
|
|
"compare" URL. The user opens / merges the MR in the browser. No `tea` CLI,
|
|
no API calls.
|
|
- **When the flow applies:** Features only. Small bug fixes and hotfixes can
|
|
still be committed straight to `main`. Claude decides feature-vs-fix based
|
|
on scope; when uncertain, ask.
|
|
- **Branch naming:** `feat/<slug>` for features, `fix/<slug>` for the
|
|
occasional bug-fix branch the user explicitly requests. `<slug>` is
|
|
kebab-case, short, descriptive.
|
|
|
|
## Change
|
|
|
|
Add a new top-level section to `CLAUDE.md` titled **"Branching & merge requests"**,
|
|
placed immediately before the existing `## Git Commits` section so the workflow
|
|
context appears before the commit-message convention.
|
|
|
|
### Proposed section content
|
|
|
|
```markdown
|
|
## Branching & merge requests
|
|
|
|
The remote is Gitea (`gitea.home.hrajfrisbee.cz/kacerr/fuj-management`).
|
|
For **features**, do not commit to `main` directly. Use a branch + merge
|
|
request flow:
|
|
|
|
1. **Create a branch off `main`** before starting work:
|
|
- `feat/<slug>` for features (e.g. `feat/qr-code-overlay`)
|
|
- `fix/<slug>` for bug-fix branches the user explicitly asks for
|
|
- `<slug>` is short kebab-case
|
|
2. **Commit on the branch** following the existing commit conventions
|
|
(Co-Authored-By trailer, etc.).
|
|
3. **Push the branch** to `origin` with `-u` so it tracks.
|
|
4. **Print the Gitea compare URL** so the user can open the MR in the
|
|
browser:
|
|
`https://gitea.home.hrajfrisbee.cz/kacerr/fuj-management/compare/main...<branch>`
|
|
Do **not** use `tea`, `gh`, or call the Gitea API — the user opens and
|
|
merges the MR themselves.
|
|
5. **Do not merge or delete the branch** from the CLI. The user does that
|
|
in Gitea.
|
|
|
|
**Exceptions — when committing straight to `main` is fine:**
|
|
- Small bug fixes / hotfixes the user describes as such.
|
|
- Typo / comment / formatting tweaks.
|
|
- Edits the user explicitly says to push to `main`.
|
|
|
|
When uncertain whether something is "feature" or "small fix", ask before
|
|
committing.
|
|
```
|
|
|
|
## Files to modify
|
|
|
|
- [CLAUDE.md](CLAUDE.md) — insert the new `## Branching & merge requests`
|
|
section just above the existing `## Git Commits` section (around line 95).
|
|
|
|
## Verification
|
|
|
|
- Re-read `CLAUDE.md` and confirm the new section is well-placed and the
|
|
existing structure (`## Git Commits`, `## Changelog`, `## Plans`) is intact.
|
|
- `git diff CLAUDE.md` should show only an additive change.
|
|
- No code, tests, or runtime behavior changes — nothing else to test.
|
|
- Behavior verification happens on the **next** feature request: Claude
|
|
should create a `feat/<slug>` branch, commit there, push, and print the
|
|
compare URL instead of committing on `main`.
|