Repository
Branch principali
Il progetto ha tre branch principali comuni a tutti i moduli:
- master: ambiente di sviluppo, dove convergono tutte le modifiche prima del rilascio
- staging: ambiente di staging e demo per test e validazione
- production: ambiente di produzione
Branch dei moduli
Ogni modulo ha un proprio branch principale denominato module/{nomeModulo} che funge da "master" per quel specifico modulo. Ad esempio:
- Modulo Metric Calculations →
module/metric-calculations - Modulo Invoices →
module/invoices - Modulo Contracts →
module/contracts
Tutti i branch di feature/fix relativi a un modulo devono partire dal branch principale di quel modulo.
Flusso delle modifiche
Le modifiche devono seguire questo flusso:
- Creazione branch feature/fix dal branch principale del modulo
- Sviluppo e test delle modifiche
- Merge dal branch feature/fix al branch principale del modulo
- Merge request dal branch principale del modulo a master
Le modifiche su master devono sempre e solo arrivare tramite merge request dai branch principali dei moduli. Gli hotfix sono l'unica eccezione a questa regola e possono essere applicati direttamente sui branch principali quando necessario ed espressamente richiesto.
Regole per i Commits
I messaggi di commit devono seguire una struttura specifica per mantenere consistenza e chiarezza nel progetto. La struttura è composta da diverse parti che devono essere presenti nell'ordine corretto.
Struttura del messaggio di commit
Il messaggio di commit deve seguire questo formato:
[scope][tipo][task] descrizione delle modifiche
Componenti del messaggio
1. Scope del modulo
La prima parte del messaggio identifica il modulo interessato dalle modifiche. Lo scope va preso dallo short name del modulo presente nel README dentro app/{nomeModulo}.
Esempio: Se il modulo si chiama InvModule, lo scope sarà [inv].
2. Tipo di intervento
Subito dopo lo scope, deve essere specificato il tipo di intervento utilizzando uno dei seguenti tag:
[hot]: Hotfix da applicare direttamente sui branch principali (master, staging, production)[fix]: Fix da implementare tramite merge request[feat]: Nuova feature o funzionalità[dbg]: Commit di debug, come inserimento di log o modifiche temporanee[wip]: Commit di work in progress[chore]: Modifiche di manutenzione, aggiornamenti di dipendenze, configurazioni[ocd]: Disturbo ossessivo compulsivo
3. Codice del task (opzionale)
Se presente, il codice del task di ClickUp va inserito tra parentesi quadre.
Esempio: [HD-1234]
4. Descrizione delle modifiche
Infine, una descrizione chiara e concisa delle modifiche effettuate, in inglese.
Esempio completo
[inv][feat][HD-1234] added validation for required fields in invoice creation form