Git Flow

Un Task corrisponde a un branch.

Ogni sviluppatore deve creare un nuovo branch partendo dal branch staging, utilizzando Linear per generare il nome del branch. Linear assegna automaticamente un nome al branch in base al task corrispondente, il che permette di mantenere la connessione tra il task su Linear e lo stato della Pull Request (PR).

In questo modo, lo stato del task su Linear sarà aggiornato automaticamente in base allo stato della PR. È fondamentale creare un branch utilizzando questa logica e non modificare manualmente il nome del branch o crearne uno senza partire da un task su Linear.

Un branch deve corrispondere a un solo task, ma può includere uno o più commit, a seconda delle aree di lavoro. I commit devono essere suddivisi utilizzando il type e lo scope indicati qui sotto.

Ogni commit segue lo standard seguente:

type(scope): descrizione

Label type

I tipi di commit accettati sono:

• chore: modifica di configurazioni o del package manager. Non comporta modifiche al codice in produzione.
• docs: modifica della documentazione
• feat: nuova funzionalità
• fix: correzione di un bug
• refactor: riscrittura del codice in produzione
• format: formattazione del codice (es. spazi, punti e virgola, ecc.)

Scope

Gli scope accettati sono:

• mediakit
• business
• smart
• report
• personal-area
• authentication
• influencer
• upgrade
• config
• general
• ai

Esempio

chore(config): aggiornamento librerie deprecate

Per maggiori informazioni sui Git Conventional Commits.

Pull Request e Merging

Una volta concluso lo sviluppo, deve essere aperta una Pull Request rispetto al branch staging e devono essere aggiunti come reviewer riccardogenova e andrenjdev. Solo in caso di approvazione da parte di entrambi, lo sviluppatore potrà eseguire il merge del branch utilizzando il processo di rebase e merge (questo è fondamentale).

In caso di sviluppi che includono modifiche alla UI, è necessario aggiungere anche yaribrugnoni tra i reviewer.

Validazione della Pull Request

All’apertura della Pull Request, GitHub lancerà una action di validazione che eseguirà il comando npm run validate, lo stesso comando che viene eseguito in locale durante la fase di commit. Questo comando si assicura che non ci siano errori in base alla configurazione typescript/eslint. In caso di esito positivo, l’integrazione con Vercel permetterà di generare un link di preview dove verrà deployato lo sviluppo, rendendo possibile testarlo direttamente online.

Notifica e gestione di segnalazioni UI

All’apertura della Pull Request, sul canale Slack #ui-bugs verrà inviata una notifica. Questa notifica sarà analizzata da un responsabile designato, Yari Brugnoni, che potrà eventualmente segnalare dei bug utilizzando la Vercel Toolbar.

Nel caso in cui vengano segnalati dei commenti sulla UI, la PR verrà automaticamente rifiutata e i commenti saranno visibili sulla PR stessa. Lo sviluppatore dovrà risolvere i problemi segnalati, effettuare un nuovo push delle modifiche sul branch e marcare i commenti come risolti, fino a quando il responsabile non approverà le modifiche.

Se durante la revisione vengono effettuate nuove modifiche, è importante richiedere una nuova review cliccando sul bottone di refresh accanto ai rispettivi reviewer. In questo modo verrà inviata una notifica via email ai reviewer interessati, per garantire che siano a conoscenza delle modifiche aggiuntive.

Conclusione del Merge

Una volta che la Pull Request è stata approvata e i bug risolti, lo sviluppatore può procedere con il merge utilizzando rebase e merge. Dopo il merge, l’ambiente di staging sarà disponibile all’indirizzo https://app-staging.notjustanalytics.com/.

Risoluzione dei conflitti

In caso di conflitti durante la Pull Request, è obbligatorio utilizzare il processo di rebase per risolverli. L’uso del merge per risolvere i conflitti non è consentito e porterà al rifiuto automatico della PR.

Modifiche richieste durante la Pull Request

In caso di richieste di modifiche durante la Pull Request, lo sviluppatore deve eseguire un commit di tipo fixup, indicando l’hash del commit di riferimento. Esempio:

git commit --fixup 03cfcd8e1bad1f3ea50076d200fe0d13308a1ab8

Dopo aver effettuato un commit di tipo fixup, è importante eseguire un rebase interactive per compattare correttamente i commit nel modo corretto.

Hotfix

Nel caso in cui venga richiesto un hotfix per correggere un bug urgente in produzione, occorre seguire una procedura specifica. In questo caso:

1. Creare un nuovo branch a partire dal branch main, utilizzando la convenzione del nome hotfix/---.
2. Svolgere la correzione del bug nel branch hotfix.
3. Aprire una Pull Request rispetto al branch main, seguendo lo stesso processo di revisione e approvazione utilizzato per i task. I reviewer richiesti sono sempre riccardogenova e andrenjdev.
4. Dopo l’approvazione, lo sviluppatore potrà eseguire il merge del branch, utilizzando sempre il processo di rebase e merge.

Una volta che la Pull Request è stata mergiata nel branch main, la correzione sarà applicata direttamente in produzione.

COMANDI

Processo di rebase interactive

Per eseguire il rebase interactive, è necessario specificare l’hash del commit precedente al primo commit di sviluppo. In questo modo, sarà possibile visualizzare tutti i nuovi commit effettuati a partire da quell’hash e decidere come ricostruire la cronologia.

Comando per il rebase interactive:

git rebase -i <hash-del-commit-precedente>

Questo comando aprirà un editor che mostrerà tutti i commit successivi all’hash specificato. A questo punto, si potrà scegliere di combinare, modificare o eliminare i commit, in modo da mantenere una cronologia pulita e coerente.

Processo di rebase per allineare il branch con staging

1. Spostarsi su staging:

   git checkout staging

2. Eseguire un pull di staging per assicurarsi di avere l’ultima versione aggiornata:

   git pull origin staging

3. Tornare al proprio branch:

   git checkout <nome-branch>

4. Eseguire il rebase del proprio branch su staging:

   git rebase staging

5. Risoluzione dei conflitti: Se ci sono conflitti durante il rebase, sarà necessario risolverli manualmente. Dopo aver risolto un conflitto, è necessario aggiungere i file risolti con:

   git add <file>

6. Proseguire con il rebase dopo aver risolto i conflitti:

   git rebase --continue

7. Ripetere i passaggi di risoluzione dei conflitti fino a quando il rebase non sarà completato.

Una volta terminato il rebase, il branch sarà aggiornato con i cambiamenti del branch staging, e sarà possibile procedere con la Pull Request senza conflitti.