Flusso di lavoro di Gitflow
Gitflow è un flusso di lavoro Git legacy che in origine ha rappresentato una strategia innovativa e dirompente di gestione dei branch Git. La popolarità di Gitflow è diminuita a favore dei flussi di lavoro basati su trunk, che ora sono considerati come best practice dello sviluppo continuo di software moderno, e delle pratiche DevOps. Inoltre, Gitflow può essere difficile da usare con CI/CD. Questo post descrive nei dettagli la storia di Gitflow.
Che cos'è Gitflow?
Gitflow è un modello di branching Git alternativo che prevede l'uso di feature branch e di più branch primari. È stato pubblicato per la prima volta e reso popolare da Vincent Driessen su nvie. Rispetto allo sviluppo basato su trunk, Gitflow ha numerosi branch di più lunga durata e commit di maggiori dimensioni. Con questo modello, gli sviluppatori creano un feature branch e ne posticipano il merge nel branch principale del trunk fino a quando la funzione non è completata. Questi feature branch di lunga durata richiedono una maggiore collaborazione per il merge e presentano un maggiore rischio di allontanarsi dal branch del trunk. Possono inoltre introdurre aggiornamenti in conflitto.
Gitflow può essere utilizzato per progetti con un ciclo di rilascio pianificato e per le best practice DevOps di continuous delivery. Questo flusso di lavoro non aggiunge nuovi concetti o comandi oltre a quanto richiesto per il flusso di lavoro del branch di funzioni. Assegna invece ruoli molto specifici ai diversi branch e definisce modi e tempi della loro interazione. Oltre ai branch feature, utilizza singoli branch per la preparazione, la gestione e la registrazione dei rilasci. Naturalmente, puoi sfruttare anche tutti i vantaggi del flusso di lavoro dei branch di funzioni: pull request, esperimenti isolati e collaborazione più efficiente.
materiale correlato
Registro Git avanzato
Scopri la soluzione
Impara a utilizzare Git con Bitbucket Cloud
Come funziona
Branch di sviluppo e branch principale
Invece di un singolo branch main, questo flusso di lavoro utilizza due branch per registrare la cronologia del progetto. Il branch main memorizza la cronologia di rilascio ufficiale e il branch develop funge da branch di integrazione per le funzioni. È inoltre molto pratico taggare tutti i commit nel branch main con un numero di versione.
Il primo passo consiste nell'integrare il branch main predefinito con un branch develop. Per procedere in modo semplice, uno sviluppatore deve creare un branch develop vuoto in locale ed eseguirne il push sul server:
git branch develop
git push -u origin developQuesto branch conterrà la cronologia completa del progetto, mentre il branch main ne conterrà una versione ridotta. Gli altri sviluppatori devono ora clonare il repository centrale e creare un branch di traccia per il branch develop.
Quando si utilizza la libreria di estensioni git-flow, l'esecuzione di git flow init su un repository esistente creerà il branch develop:
$ git flow init
Initialized empty Git repository in ~/project/.git/
No branches exist yet. Base branches must be created now.
Branch name for production releases: [main]
Branch name for "next release" development: [develop]
How to name your supporting branch prefixes?
Feature branches? [feature/]
Release branches? [release/]
Hotfix branches? [hotfix/]
Support branches? [support/]
Version tag prefix? []
$ git branch
* develop
mainBranch di funzioni
Passaggio 1. Creazione del repository
Ogni nuova funzione deve risiedere nel proprio branch, di cui può essere eseguito il push al repository centrale a fini di backup/collaborazione. Ma, invece di diramarsi dal branch main, i branch feature usano il branch develop come branch principale. Quando una funzione è completa, ne viene eseguito nuovamente il merge nel branch develop. Le funzioni non devono mai interagire direttamente con il branch main.
Nota che i branch feature uniti con il branch develop costituiscono a tutti gli effetti il flusso di lavoro del branch di funzioni. Tuttavia, il flusso di lavoro di Gitflow non si ferma qui.
I branch feature vengono generalmente creati a partire dal branch develop più recente.
Creazione di un branch di funzioni
Senza le estensioni git-flow:
git checkout develop
git checkout -b feature_branchSe si utilizza l'estensione git-flow:
git flow feature start feature_branchContinua a lavorare utilizzando Git come faresti normalmente.
Completamento di un branch di funzioni
Quando hai terminato il lavoro di sviluppo della funzione, il passo successivo è quello di eseguire il merge di feature_branch in develop.
Senza le estensioni git-flow:
git checkout develop
git merge feature_branchCon le estensioni git-flow:
git flow feature finish feature_branchBranch di rilascio
Una volta che develop ha acquisito un numero sufficiente di funzioni per effettuare un rilascio (o si sta avvicinando una data di rilascio prestabilita), esegui un fork di un branch release da develop. La creazione di questo branch avvia il ciclo di rilascio successivo, pertanto non è possibile aggiungere nuove funzioni dopo questo punto: devono essere inseriti in questo branch solo correzioni di bug, la creazione di documentazione e altri task orientati al rilascio. Quando è tutto pronto per il rilascio, viene eseguito il merge del branch release in main e il branch viene contrassegnato con un numero di versione. Inoltre, dovrebbe esserne eseguito nuovamente il merge in develop, che nel frattempo potrebbe essere avanzato dall'inizio del rilascio.
L'utilizzo di un branch dedicato per preparare i rilasci consente a un team di perfezionare il rilascio corrente mentre un altro team continua a lavorare sulle funzioni per il prossimo rilascio. Crea anche fasi di sviluppo ben definite (ad esempio, diventa facile programmare la preparazione alla versione 4.0 per la settimana in corso e vedere effettivamente tale versione nella struttura del repository).
Creare branch release è un'altra semplice operazione di creazione di branch. Come i branch feature, quelli release si basano sul branch develop. È possibile creare un nuovo branch release utilizzando i seguenti metodi.
Senza le estensioni git-flow:
git checkout develop
git checkout -b release/0.1.0Se si utilizzano le estensioni git-flow:
$ git flow release start 0.1.0
Switched to a new branch 'release/0.1.0'Una volta che il rilascio è pronto, ne verrà eseguito il merge in main e develop, quindi il branch release verrà eliminato. È importante eseguire nuovamente il merge in develop perché potrebbero essere stati aggiunti aggiornamenti critici al branch release che devono essere accessibili alle nuove funzioni. Se la tua organizzazione dà molta importanza alla revisione del codice, questo è il luogo ideale per eseguire una pull request.
Per completare un branch release, utilizza i seguenti metodi:
Senza le estensioni git-flow:
git checkout main
git merge release/0.1.0Oppure con l'estensione git-flow:
git flow release finish '0.1.0'Branch di correzione rapida
I branch di manutenzione, o "hotfix", vengono utilizzati per applicare rapidamente patch ai rilasci di produzione. I branch hotfix sono molto simili ai branch release e feature, tranne per il fatto che sono basati sul branch main anziché sul branch develop. Sono gli unici branch che dovrebbero eseguire un fork direttamente dal branch main. Non appena la correzione è completa, ne dovrebbe essere eseguito il merge sia in main che in develop (o nel branch release corrente) e al branch main dovrebbe essere aggiunto un tag con un numero di versione aggiornato.
Avere una linea di sviluppo dedicata per le correzioni dei bug consente al team di gestire i ticket senza interrompere il resto del flusso di lavoro o attendere il prossimo ciclo di rilascio. Puoi immaginare i branch di manutenzione come branch release ad hoc che funzionano direttamente con il branch main. È possibile creare un branch hotfix utilizzando i seguenti metodi:
Senza le estensioni git-flow:
git checkout main
git checkout -b hotfix_branchSe si utilizzano le estensioni git-flow:
$ git flow hotfix start hotfix_branchCome accade per il completamento di un branch release, viene eseguito il merge del branch hotfix sia nel branch main che nel branch develop.
git checkout main
git merge hotfix_branch
git checkout develop
git merge hotfix_branch
git branch -D hotfix_branch$ git flow hotfix finish hotfix_branchEsempio
Di seguito è riportato un esempio completo del flusso di un branch di funzioni in cui si parte dal presupposto che il repository sia stato configurato con un branch main.
git checkout main
git checkout -b develop
git checkout -b feature_branch
# work happens on feature branch
git checkout develop
git merge feature_branch
git checkout main
git merge develop
git branch -d feature_branchOltre al flusso dei branch feature e release, un esempio del branch hotfix è il seguente:
git checkout main
git checkout -b hotfix_branch
# work is done commits are added to the hotfix_branch
git checkout develop
git merge hotfix_branch
git checkout main
git merge hotfix_branchRiepilogo
Qui abbiamo parlato del flusso di lavoro di Gitflow. Gitflow è uno dei tanti stili di flussi di lavoro Git che tu e il tuo team potete utilizzare.
Alcuni concetti chiave da conoscere su Gitflow sono:
- Questo flusso di lavoro è ottimo per un flusso di lavoro software basato sul rilascio.
- Gitflow offre un canale dedicato per le correzioni rapide nell'ambiente di produzione.
Il flusso generale di Gitflow è:
1. Un branch develop viene creato a partire dal branch main
2. Un branch release viene creato a partire dal branch develop
3. I branch feature vengono creati a partire dal branch develop
4. Quando un branch feature è completo, ne viene eseguito il merge nel branch develop
5. Quando il branch release è completo, ne viene eseguito il merge nei branch develop e main
6. Se viene rilevato un problema nel branch main, viene creato un branch hotfix a partire dal branch main
7. Una volta completato il branch hotfix, ne viene eseguito il merge sia nel branch develop che nel branch main
Scopri di più sul flusso di lavoro di fork o visita la nostra pagina di confronto dei flussi di lavoro.
Condividi l'articolo
Argomento successivo
Letture consigliate
Aggiungi ai preferiti queste risorse per ricevere informazioni sui tipi di team DevOps e aggiornamenti continui su DevOps in Atlassian.
Blog di Bitbucket
Percorso di apprendimento DevOps
