docs: add branching strategy — master, develop, feature/* model

This commit is contained in:
Joakim Mörling 2026-04-30 15:34:00 +02:00
parent 03010f2fd8
commit f2c1a9e2d6
2 changed files with 39 additions and 6 deletions

View file

@ -115,6 +115,11 @@ Full details in `@CODING_GUIDELINES.md`. Key rules:
- No commented-out code. Delete it.
- Functions stay small (<30 lines).
### Git
- Create `feature/*`, `fix/*`, or `chore/*` branches from `develop`.
- Never commit directly to `master` or `develop`.
- Merge strategy: fast-forward or merge — either is fine.
### Frontend (Vue.js 3)
- `<script setup>` with Composition API only. Never Options API.
- File naming: PascalCase for pages/components, camelCase (`useXxx`) for composables.

View file

@ -20,6 +20,40 @@ Conventions and standards for the BilHej codebase. These exist to keep the proje
## 2. Git
### Branch Model
Three permanent branches, plus short-lived work branches:
```
master ──────────────────────────────────────●──● (production, deployed)
↗ ↗
develop ────────●──────────●────────●───────●──● (integration)
↗ ↗ ↗
feature/foo ──●──●──●───→┘ │
feature/bar ───────────────────────●──●─────→┘
```
| Branch | Purpose | Branches from | Merges to |
|--------|---------|---------------|-----------|
| `master` | Production — what runs on the server | — | — |
| `develop` | Integration — all work branches land here | `master` | `master` (on release) |
| `feature/*` | New feature work | `develop` | `develop` |
| `fix/*` | Bug fix | `develop` | `develop` |
| `chore/*` | Maintenance, upgrades, docs | `develop` | `develop` |
### Rules
- **Never commit directly to `master` or `develop`.** All work happens in feature/fix/chore branches.
- **Merge strategy**: fast-forward or merge — either is fine for a solo dev project. Prefer simple over complex.
- **Keep branches short-lived.** Merge back to `develop` within a few days. Don't let branches drift.
- **Update before merging.** Pull latest `develop` into your branch before merging back to avoid surprises.
- **Tag releases on `master`**: `v0.1.0`, `v0.2.0`, etc. These mark deployable states.
- **Rebase**: only rebase your own unpublished branches. Once pushed/shared, merge instead.
- **CI triggers**: push to `develop` → run tests. Push to `master` → run tests + deploy.
- **Squash trivial fix commits** before pushing (typo fixes, formatting, etc.).
- **Never commit `.env`, credentials, or secrets. `.env.example` only.**
### Branch Naming
```
@ -41,12 +75,6 @@ chore: bump vue to 3.5
Types: `feat`, `fix`, `refactor`, `chore`, `docs`, `test`, `style`
### Workflow
- Work directly on `main` until you have a reason not to (MVP phase).
- Squash trivial fix commits before pushing.
- Never commit `.env`, credentials, or secrets. `.env.example` only.
---
## 3. Frontend — Vue.js 3