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

Requisiti

Per poter installare ed utilizzare correttamente monkeflow ti servono:

• git
• make
• gh (GitHub-cli)

Devi anche aver configurato il comando gh. Una volta installato (vedi https://cli.github.com/) esegui il comando

gh auth login

segui le semplici istruzioni ed autenticati.

Per verificare se la procedura ha avuto successo usa

gh auth status

Installazione

Prima di tutto assicurati di non avere già installato gitflow in precedenza, nel caso provvedi a rimuoverlo.
Poi inizia con il clonare la repo con il comando:

git clone https://github.com/Typing-Monkeys/monkeflow.git

entra nella repo ed avvia l'installazione:

cd monkeflow
sudo make install

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.