Branching

Branching

La nomenclatura dei branch è fondamentale per mantenere ordine durante lo sviluppo. Abbiamo optato per la seguente gerarchia:

• il branch master corrisponde al canonico branch production;
• il branch staging corrisponde al canonico branch develop;

Durante lo sviluppo del progetto abbiamo lavorato su vari branch derivati da staging, in particolare:

• branch feature-user, che racchiude lo sviluppo delle varie user stories relative alle gestione degli utenti;
• branch feature-recipe, che racchiude i servizi di ricerca e visualizzazione delle ricette;
• branch feature-plan, che racchiude il processo di creazione e visualizzazione dei piani alimentari;
• branch feature-preferences, nel quale abbiamo implementato gli aspetti di gestione delle preferenze di un utente per creare dei piani basati sui suoi gusti;
• branch feature-favorites, che è stato usato per la scrittura del codice riguardante la gestione dei piani preferiti da un utente;
• branch feature-plan-advanced, in cui abbiamo inserito tutta la logica di generazione piano avanzata, ovvero la generazione di un piano in cui vengono soddisfatte le preferenze di un utente;
• vari branch api-*, per la stesura della documentazione dell'api;
• vari branch fix-*, per risolvere bug introdotti (nota: non abbiamo creato dei branch nel caso il problema fosse stato risolvibile solo con un commit di piccole dimensioni);
• vari branch restyling-*, dove abbiamo puntato al restyiling grafico del sistema, soprattutto dopo i feedback che abbiamo ricevuto dopo il primo sprint.

Principalmente abbiamo utilizzato il branch staging come singolo punto di incontro per i test di integrazione prima di passare il tutto al branch di production. In aggiunta, nessun commit è stato direttamente eseguito sul branch master: l'unica possibilità di modificare il branch di production è attraverso dei merge.