127 lines
2.2 KiB
Markdown
127 lines
2.2 KiB
Markdown
|
# 🤝 Contribuer à Veza
|
|||
|
|
|
|||
|
|
Merci de contribuer à Veza !
|
|||
|
|
Ce guide formalise un workflow clair, reproductible et adapté à la complexité du projet.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
# 1. Philosophie du projet
|
|||
|
|
|
|||
|
|
Veza suit trois principes :
|
|||
|
|
|
|||
|
|
1. **Cohérence** — respecter la structure ORIGIN (docs/ORIGIN/).
|
|||
|
|
2. **Lisibilité** — code clair, typé, testé, documenté.
|
|||
|
|
3. **Évolutivité** — préférer une architecture modulaire à un hack rapide.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
# 2. Branching Model
|
|||
|
|
|
|||
|
|
- `main` : toujours stable, toujours déployable.
|
|||
|
|
- `develop` (optionnel) : branche d’intégration continue.
|
|||
|
|
- Branches par fonctionnalité :
|
|||
|
|
|
|||
|
|
````
|
|||
|
|
|
|||
|
|
feat/<nom-fonction>
|
|||
|
|
fix/<bug>
|
|||
|
|
chore/<tâche-technique>
|
|||
|
|
refactor/<refacto>
|
|||
|
|
docs/<documentation>
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
Exemples :
|
|||
|
|
|
|||
|
|
- `feat/auth-refresh-tokens`
|
|||
|
|
- `fix/jwt-uuid-mismatch`
|
|||
|
|
- `refactor/chat-room-architecture`
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
# 3. Convention de commits
|
|||
|
|
|
|||
|
|
Suivre le style **Conventional Commits** :
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
feat: ajout fonctionnalité
|
|||
|
|
fix: correction de bug
|
|||
|
|
chore: tâches automatiques, maj deps
|
|||
|
|
docs: ajout ou mise à jour docs
|
|||
|
|
refactor: restructuration sans changement de comportement
|
|||
|
|
test: ajout/màj tests
|
|||
|
|
ci: pipeline CI/CD
|
|||
|
|
|
|||
|
|
````
|
|||
|
|
|
|||
|
|
Exemples :
|
|||
|
|
|
|||
|
|
- `feat: add adaptive HLS transcoding worker`
|
|||
|
|
- `fix: correct JWT user_id mismatch between Go and Rust`
|
|||
|
|
- `refactor: isolate DM module in chat-server`
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
# 4. Tests & Qualité
|
|||
|
|
|
|||
|
|
Avant toute PR :
|
|||
|
|
|
|||
|
|
1. Lancer les tests Go :
|
|||
|
|
```bash
|
|||
|
|
go test ./...
|
|||
|
|
````
|
|||
|
|
|
|||
|
|
2. Lancer les tests Rust :
|
|||
|
|
|
|||
|
|
```bash
|
|||
|
|
cargo test
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
3. Lancer les tests du frontend :
|
|||
|
|
|
|||
|
|
```bash
|
|||
|
|
pnpm test
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
4. Vérifier lfmt / clippy :
|
|||
|
|
|
|||
|
|
```bash
|
|||
|
|
cargo fmt --all --check
|
|||
|
|
cargo clippy -- -D warnings
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
5. Vérifier go vet :
|
|||
|
|
|
|||
|
|
```bash
|
|||
|
|
go vet ./...
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
# 5. Pull Requests
|
|||
|
|
|
|||
|
|
1. Toujours ouvrir une PR, même si vous êtes seul.
|
|||
|
|
2. Décrire :
|
|||
|
|
|
|||
|
|
* Contexte
|
|||
|
|
* Changement
|
|||
|
|
* Impact sur l'architecture ORIGIN
|
|||
|
|
* Migrations nécessaires ?
|
|||
|
|
* Compatibilité ascendante ?
|
|||
|
|
3. Ajouter des captures si c’est du frontend.
|
|||
|
|
4. Pas de merge si CI échoue.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
# 6. Documentation
|
|||
|
|
|
|||
|
|
* Tout changement significatif doit être reflété dans `docs/`.
|
|||
|
|
* Si une décision touche à l’architecture : mettre à jour la section `ORIGIN`.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
Merci de rendre Veza meilleur !
|
|||
|
|
|
|||
|
|
|