Cos’è GitFlow?
GitFlow è un modello di branching per Git, creato da Vincent Driessen. Ha attirato molta attenzione perché è molto adatto alla collaborazione e allo scaling del team di sviluppo.
Benefici chiave
Sviluppo parallelo
Una delle grandi cose di GitFlow è che rende molto facile lo sviluppo parallelo, isolando il nuovo sviluppo dal lavoro finito. Il nuovo sviluppo (come le caratteristiche e le correzioni di bug non urgenti) è fatto nei rami delle caratteristiche, e viene riportato nel corpo principale del codice solo quando lo sviluppatore (o gli sviluppatori) sono felici che il codice sia pronto per il rilascio.
Anche se le interruzioni sono una cosa negativa, se ti viene chiesto di passare da un compito ad un altro, tutto quello che devi fare è impegnare le tue modifiche e poi creare un nuovo ramo delle caratteristiche per il tuo nuovo compito. Quando quel compito è finito, basta fare il checkout del ramo originale e si può continuare da dove si è lasciato.
Collaborazione
I rami di feature rendono anche più facile per due o più sviluppatori collaborare sulla stessa feature, perché ogni ramo di feature è una sandbox dove le sole modifiche sono quelle necessarie per far funzionare la nuova feature. Questo rende molto facile vedere e seguire ciò che ogni collaboratore sta facendo.
Release Staging Area
Quando un nuovo sviluppo viene completato, viene fuso nuovamente nel ramo develop, che è un’area di sosta per tutte le caratteristiche completate che non sono ancora state rilasciate. Così, quando il prossimo rilascio viene diramato da develop, conterrà automaticamente tutto il nuovo materiale che è stato completato.
Supporto per le correzioni di emergenza
GitFlow supporta i rami hotfix – rami fatti da un rilascio con tag. Puoi usarli per fare un cambiamento di emergenza, con la certezza che l’hotfix conterrà solo la tua correzione di emergenza. Non c’è il rischio di unire accidentalmente un nuovo sviluppo allo stesso tempo.
Come funziona
I nuovi sviluppi (nuove funzionalità, correzioni di bug non di emergenza) sono costruiti in rami di funzionalità:
I rami di funzionalità sono separati dal ramo di sviluppo, e le funzionalità e le correzioni finite sono unite nuovamente nel ramo di sviluppo quando sono pronte per il rilascio:
Quando è il momento di fare un rilascio, viene creato un ramo di rilascio da quello di sviluppo:
Il codice nel ramo di rilascio viene distribuito su un ambiente di test adatto, testato, e qualsiasi problema viene risolto direttamente nel ramo di rilascio. Questo deploy -> test -> fix -> redeploy -> retest cycle continua finché non si è felici che il rilascio sia abbastanza buono da essere rilasciato ai clienti.
Quando il rilascio è finito, il ramo di rilascio viene unito al master e anche allo sviluppo, per assicurarsi che qualsiasi cambiamento fatto nel ramo di rilascio non venga accidentalmente perso dal nuovo sviluppo.
Il ramo master traccia solo il codice rilasciato. Gli unici commit su master sono fusioni da rami di rilascio e rami hotfix.
I rami hotfix sono usati per creare correzioni di emergenza:
Sono ramificati direttamente da un rilascio taggato nel ramo master, e quando finiscono vengono fusi di nuovo sia nel master che nello sviluppo per essere sicuri che l’hotfix non venga accidentalmente perso al successivo rilascio regolare.
0 commenti