bruno
47b0f80dfe
- ROADMAP.md: réorganisé avec priorités claires (v4.0.0=complété, v4.0.1=onboarding PRIO MAX) - Ajout BRANCHING.md: convention main/develop/feat/*, workflow complet - Branche develop créée et poussée sur Gitea - Sections Parité Notion réparties en v4.1–v4.10 ordonnées par priorité - Résumé des phases mis à jour
109 lines
3.1 KiB
Markdown
109 lines
3.1 KiB
Markdown
# Stratégie de branches — FlowDeck
|
|
|
|
## Structure
|
|
|
|
```
|
|
main ──●────────────●────── production (tags vX.Y.Z)
|
|
\ /
|
|
develop ●──●──●──●────── intégration continue
|
|
\ \ \
|
|
feat/xxx ● ● ●──── feature branches
|
|
fix/xxx ●─────────── hotfix branches
|
|
```
|
|
|
|
## Branches
|
|
|
|
| Branche | Rôle | Déploiement | Protection |
|
|
|---------|------|-------------|------------|
|
|
| `main` | Production | Docker auto sur :8080 | Push direct interdit, PR only |
|
|
| `develop` | Intégration | Staging (optionnel) | Push direct interdit, PR only |
|
|
| `feat/<nom>` | Nouvelle feature | Aucun | Libre |
|
|
| `fix/<nom>` | Correctif urgent | Aucun | Libre |
|
|
|
|
## Workflow quotidien
|
|
|
|
### 1. Démarrer une feature
|
|
|
|
```bash
|
|
git checkout develop
|
|
git pull origin develop
|
|
git checkout -b feat/ma-feature
|
|
```
|
|
|
|
### 2. Travailler
|
|
|
|
```bash
|
|
# Coder, commit souvent
|
|
git add -A
|
|
git commit -m "feat: description claire de ce qui est fait"
|
|
git push origin feat/ma-feature
|
|
```
|
|
|
|
### 3. Créer une Pull Request
|
|
|
|
Aller sur https://git.dracodev.net/bruno/flowdeck/pulls
|
|
- **Base** : `develop`
|
|
- **Head** : `feat/ma-feature`
|
|
- Titre : descriptif
|
|
- Assigner un reviewer si applicable
|
|
|
|
### 4. Après merge
|
|
|
|
```bash
|
|
git checkout develop
|
|
git pull origin develop
|
|
git branch -d feat/ma-feature # supprimer la branche locale
|
|
```
|
|
|
|
## Release (develop → main)
|
|
|
|
```bash
|
|
# 1. S'assurer que develop est prêt
|
|
git checkout develop
|
|
git pull origin develop
|
|
|
|
# 2. Créer une PR develop → main sur Gitea
|
|
# (ou merger localement si admin)
|
|
git checkout main
|
|
git merge develop
|
|
git tag v4.0.1
|
|
git push origin main --tags
|
|
```
|
|
|
|
## Hotfix urgent
|
|
|
|
```bash
|
|
git checkout main
|
|
git checkout -b fix/urgence
|
|
# ... corriger ...
|
|
git commit -m "fix: description"
|
|
git push origin fix/urgence
|
|
# PR fix/urgence → main
|
|
# PUIS merger main → develop pour synchroniser
|
|
git checkout develop
|
|
git merge main
|
|
git push origin develop
|
|
```
|
|
|
|
## Conventions de commits
|
|
|
|
| Préfixe | Usage | Exemple |
|
|
|---------|-------|---------|
|
|
| `feat:` | Nouvelle fonctionnalité | `feat: landing page for visitors` |
|
|
| `fix:` | Correction de bug | `fix: redirect loop on /` |
|
|
| `refactor:` | Restructuration sans changement fonctionnel | `refactor: extract sidebar_data` |
|
|
| `test:` | Ajout/modification de tests | `test: onboarding flow e2e` |
|
|
| `docs:` | Documentation | `docs: update ROADMAP.md` |
|
|
| `style:` | Formatage, CSS | `style: mobile sidebar fixes` |
|
|
| `chore:` | Tâches de maintenance | `chore: bump version to 4.0.1` |
|
|
|
|
## Règles
|
|
|
|
1. **Jamais de push direct sur `main`** — toujours via PR depuis `develop` ou `fix/*`
|
|
2. **Jamais de push direct sur `develop`** — toujours via PR depuis `feat/*` ou `fix/*`
|
|
3. **Une branche = une feature / un fix** — éviter les branches fourre-tout
|
|
4. **Tests passent avant merge** — CI Gitea Actions doit être verte
|
|
5. **Commit + push après chaque modification significative**
|
|
6. **Nom de branche en kebab-case** : `feat/landing-page`, `fix/login-redirect`
|
|
7. **Supprimer la branche après merge** (sauf `main` et `develop`)
|