monkeflow Workflow 🦍

La repo è gestita utilizzando il monkeflow Workflow 🦍, una politica di gestione dei branch e dello sviluppo del codice basata sulla già ben nota e consolidata gitflow-avh. Di seguito una breve introduzione al funzionamento

Funzionamento

gitflow-avh è un modo per gestire lo sviluppo del codice di una repo altamente incentrato nel lavoro in team. Si basa su 2 tipologie princiapli di banch:

• permanenti: sono i branch che non verranno mai eliminati e conterranno lo storico delle release (codice stabile) e delle ultimissime modifiche ancora in sviluppo (codice in alpha o beta). Questi sono generalmente 2:
  • main o master, per le versioni stabili
  • develop o dev, per il codice ancora in sviluppo
• effimeri: branch che vengono utilizzati per la creazione di feature o risoluzione di problemi urgenti che, una volta uniti con un merge ad uno dei branch permanenti, verranno distrutti per sempre.

Per quanto riguarda i branch effimeri ne esistono alcune tipologie, di seguito quelle che ci serviranno:

• feature: rappresenta una nuova feature che deve essere implementata ed introdotta nel codice in sviluppo. Partono tutte dal branch develop e hanno nomi del tipo: feature/logs, feature/newpage, ecc. Quando lo sviluppo di della funzionalità è completo, questi vengono uniti, con un merge, solo e soltanto al branch develop.
• release: è un branch che viene creata partendo dal develop e ha lo scopo di andare a stabilizzare il codice per effettuarne la release e renderlo pronto alla produzione. Una volta completato il loro sviluppo vengono uniti al branch main e develop. Questo doppio merge serve per salvare la release nel main e comunque per non perdere le modifiche fatte durante la stabilizzazione del codice che il branch develop non avrebbe.
• hotfix: quando abbiamo rilasciato una release e ci accorgiamo che è presente un grave bug che mina il funzionamento del codice possiamo intervenire repentinamente utilizzando un hotfix. Questo branch parte direttamente dal main e una volta completati i fix, questo viene unito al main e al develop. Questa metodologia permette di apportare modifiche mirate senza dover passare per tutti i vari passaggi visti prima.

Per saperne di più guarda https://nvie.com/posts/a-successful-git-branching-model/

Il nostro monkeflow Workflow 🦍 differisce leggermente dall'originale gitflow-avh in quanto, una volta terminata una feature, release, ecc. aprirà in automatico una Pull Request su GitHub invece che effettuare il merge localmente.

N.B.: il codice non è tra i più robusti e sicuramente ci sarà qualche problema, ma se ti attiene alla seguente sezione tutto dovrebbe andare liscio

Utilizzo

Repo Init

Quando effetti il clone di una repo (che sia nuova o che utilizzi già gitflow/monkeflow) devi inizializzarla per dire a git come utilizzare il workflow. Esegui il seguente comando:

git monke init

Ti verrà chiesto di scegliere il branch di release (il main o master), il branch di sviluppo (develop o devel) e altre informazioni. Se la repo è già stata inizializzata in precedenza assicurati che i branch che ti suggerisce in automatico siano corretti. Per le altre impostazioni puoi andare sempre avanti premendo invio e scegliere quelle di default.

New Feature

Per creare una nuova feature ti basterà usare il seguente comando

git monke feature start <nome feature>

Per esempio, se volessi creare una nuova feature per la gestione dei log, dovrei utilizzare il comando git monke feature start log. Verrà creato il branch feature/log e verrà automaticamente settato come branch attuale (viene fatto il checkout di quel branch).

Posso ora iniziare a lavorarci ed effettuare normalmente commit (git commit).

Quando la feature è completa, userò il seguente comando per segnalarne il completamento:

git monke feature finish

N.B.: è molto importate che questo comando venga fatto solo quando mi trovo nel branch che riguarda la feature che voglio terminare !!

Verrà ora effettuato un push del codice e del branch su GitHub e verrà avviata la procedura per creare la Pull Request. Verrà mostrato a terminale un prompt per inserire alcuni dati:

• Titolo della PR, se lasciato vuoto avrà il nome del branch
• Body, il corpo della PR. Può anche essere lasciato vuoto e completato su GitHub in un secondo momento.
• verrà mostrata un'ultima scelta e dovrai selezionare Submit

Ora potrai aprire GitHub per controllare la PR e suggerire modifiche, approvarla o controllare il codice che è stato aggiornato.

Problemi

• Ricorda che devi autenticarti con gh per far si che sia in grado di aprire PR !
• Se la procedura non va a buon fine vuol dire che probabilmente non hai eseguito gh repo set-default !

New Release

La procedura per avviare una nuova release è simile a quella per le feature.

git monke release start <nome release>

Se volessi avviare la release 1.0 uso il comando git monke release start 1.0. Verrà creato il nuovo branch release/1.0 e ne verrà fatto il checkout.

Posso ora aggiungere commit e quando è terminato lo sviluppo uso il comando

git monke release finish

N.B.: è molto importate che questo comando venga fatto solo quando mi trovo nel branch che riguarda la release che voglio terminare !!

Verrà ora effettuato un push del codice e del branch su GitHub e verrà avviata la procedura per creare le Pull Request. Verrà mostrato a terminale un prompt per inserire alcuni dati:

• Titolo della PR, se lasciato vuoto avrà il nome del branch
• Body, il corpo della PR. Può anche essere lasciato vuoto e completato su GitHub in un secondo momento.
• verrà mostrata un'ultima scelta e dovrai selezionare Submit

Questo prompt verrà mostrato 2 volte in quanto vengono create 2 PR, una per il branch main e una per il develop !!

Ora potrai aprire GitHub per controllare le PR e suggerire modifiche, approvarle o controllare il codice che è stato aggiornato.