5 Git workflows e branching strategy che puoi usare per migliorare il tuo processo di sviluppo
Non ho mai incontrato uno sviluppatore che guardasse un messaggio di conflitto e non si strappasse i capelli dalla frustrazione.
Tentare di risolvere ogni conflitto di merge è una di quelle cose che ogni sviluppatore odia. Specialmente se ti colpisce quando ti stai preparando per un deploy di produzione!
Ecco dove avere il giusto flusso di lavoro Git impostato può fare un mondo di bene per il tuo flusso di lavoro di sviluppo.
Ovviamente, avere il giusto workflow di Git non risolverà tutti i vostri problemi. Ma è un passo nella giusta direzione. Dopotutto, con ogni team che lavora in remoto, la necessità di costruire caratteristiche insieme senza che la vostra codebase venga interrotta è critica.
Come lo impostate dipende dal progetto a cui state lavorando, dai programmi di rilascio che il vostro team ha, dalla dimensione del team, e altro ancora!
In questo articolo, vi guideremo attraverso 5 diversi flussi di lavoro git, i loro benefici, i loro contro, e quando dovreste usarli. Andiamo!
Flusso di lavoro Git di base
Il flusso di lavoro git più semplice è quello in cui c’è solo un ramo – il ramo master. Gli sviluppatori fanno il commit direttamente su di esso e lo usano per il deploy nell’ambiente di staging e di produzione.
Questo flusso di lavoro non è solitamente raccomandato a meno che non si stia lavorando ad un progetto secondario e si voglia iniziare rapidamente.
Siccome c’è solo un ramo, non c’è davvero nessun processo qui. Questo rende facile iniziare con Git. Tuttavia, alcuni svantaggi da tenere a mente quando si usa questo flusso di lavoro sono:
- La collaborazione sul codice porterà a molteplici conflitti.
- Le possibilità di spedire software difettoso in produzione è più alta.
- Mantenere il codice pulito è più difficile.
Git Feature Branch Workflow
Il Git Feature Branch workflow diventa un must quando si ha più di uno sviluppatore che lavora sullo stesso codebase.
Immaginate di avere uno sviluppatore che sta lavorando su una nuova funzionalità. E un altro sviluppatore che lavora su una seconda funzionalità. Ora, se entrambi gli sviluppatori lavorano sullo stesso ramo e vi aggiungono dei commit, il codebase diventerebbe un enorme casino con molti conflitti.
Per evitare questo, i due sviluppatori possono creare due rami separati dal ramo master e lavorare alle loro feature individualmente. Quando hanno finito la loro caratteristica, possono poi unire il loro rispettivo ramo al ramo master, e distribuire senza dover aspettare che la seconda caratteristica sia completata.
I vantaggi di usare questo flusso di lavoro è che il flusso di lavoro del ramo delle caratteristiche di Git permette di collaborare sul codice senza doversi preoccupare dei conflitti di codice.
Flusso di lavoro delle caratteristiche di Git con il ramo di sviluppo
Questo flusso di lavoro è uno dei flussi di lavoro più popolari tra i team di sviluppo. È simile al flusso di lavoro Git Feature Branch con un ramo di sviluppo che viene aggiunto in parallelo al ramo master.
In questo flusso di lavoro, il ramo master riflette sempre uno stato pronto per la produzione. Ogni volta che il team vuole fare il deploy in produzione, lo fa dal ramo master.
Il ramo di sviluppo riflette lo stato con le ultime modifiche di sviluppo per il prossimo rilascio. Gli sviluppatori creano rami dal ramo di sviluppo e lavorano su nuove caratteristiche. Una volta che la caratteristica è pronta, viene testata, unita al ramo di sviluppo, testata con il codice del ramo di sviluppo nel caso ci sia stata una fusione precedente, e poi unita al master.
Il vantaggio di questo flusso di lavoro è che permette ai team di unire costantemente nuove funzionalità, testarle in staging e distribuirle in produzione. Mentre il mantenimento del codice è più facile, può diventare un po’ noioso per alcuni team poiché può sembrare di passare attraverso un processo noioso.
Gitflow Workflow
Il workflow gitflow è molto simile al precedente workflow che abbiamo discusso combinato con altri due rami – il ramo di rilascio e il ramo hot-fix.
Il ramo hot-fix
Il ramo hot-fix è l’unico ramo che viene creato dal ramo master e direttamente unito al ramo master invece che al ramo di sviluppo. Viene usato solo quando si deve rapidamente correggere un problema di produzione. Un vantaggio di questo ramo è che permette di distribuire rapidamente un problema di produzione senza interrompere il flusso di lavoro degli altri o senza dover aspettare il prossimo ciclo di rilascio.
Una volta che la correzione viene unita al ramo master e distribuita, dovrebbe essere unita sia al ramo di sviluppo che al ramo di rilascio corrente. Questo viene fatto per assicurare che chiunque faccia un fork da develop per creare un nuovo ramo di funzionalità abbia il codice più recente.
Il ramo di rilascio
Il ramo di rilascio viene fatto un fork dal ramo di sviluppo dopo che il ramo di sviluppo ha tutte le funzionalità pianificate per il rilascio unite in esso con successo.
Nessun codice relativo a nuove funzionalità viene aggiunto nel ramo di rilascio. Solo il codice che si riferisce al rilascio viene aggiunto al ramo di rilascio. Per esempio, la documentazione, le correzioni dei bug e altri compiti relativi a questo rilascio vengono aggiunti a questo ramo.
Una volta che questo ramo viene unito al master e distribuito in produzione, viene anche unito di nuovo al ramo di sviluppo, in modo che quando una nuova caratteristica viene rimossa dal ramo di sviluppo, questo ha il codice più recente.
Questo flusso di lavoro è stato pubblicato e reso popolare da Vincent Driessen e da allora è stato ampiamente utilizzato dalle organizzazioni che hanno un ciclo di rilascio programmato.
Siccome git-flow è un wrapper intorno a Git, potete installare git-flow nel vostro repository attuale. È un processo semplice e non cambia nulla nel vostro repository oltre a creare rami per voi.
Per installare su una macchina Mac, eseguite brew install git-flow nel vostro terminale.
Per installare su una macchina Windows, dovrete scaricare e installare git-flow. Dopo l’installazione, eseguite il seguente comando Git git flow init per usarlo nel vostro progetto.
Flusso di lavoro Git Fork
Il flusso di lavoro Fork è popolare tra i team che usano software open-source.
Il flusso solitamente assomiglia a questo:
- Lo sviluppatore fa un fork del repository ufficiale del software open-source. Una copia di questo repository viene creata nel loro account.
- Lo sviluppatore poi clona il repository dal suo account al suo sistema locale.
- Un percorso remoto per il repository ufficiale viene aggiunto al repository che viene clonato sul sistema locale.
- Lo sviluppatore crea un nuovo ramo di funzionalità nel proprio sistema locale, apporta delle modifiche e le commette.
- Queste modifiche insieme al ramo vengono spinte alla copia del repository dello sviluppatore sul proprio account.
- Una richiesta di pull dal ramo viene aperta al repository ufficiale.
- Il manager del repository ufficiale controlla le modifiche e le approva per essere unite nel repository ufficiale.
Automatizzare i flussi di lavoro Git e la strategia di branching per una migliore produttività
Una delle cose con cui gli sviluppatori devono costantemente destreggiarsi è aggiornare il loro strumento di gestione del progetto per tenere aggiornati i compagni di squadra. Ecco perché, alla Zepel, i nostri sviluppatori automatizzano il loro flusso di lavoro, in modo che possano dedicare più tempo alla costruzione del software.
Ecco come automatizziamo il nostro flusso di lavoro git per mantenere tutti sincronizzati:
Mentre Zepel si integra profondamente con GitHub, Bitbucket e GitLab, noi usiamo GitHub internamente. Quindi, una volta che abbiamo integrato GitHub con Zepel, il nostro team di sviluppo imposta l’automazione del flusso di lavoro git all’interno di Zepel. Ecco come appare oggi:
Quando gli sviluppatori continuano a fare progressi, il nostro team riceve automaticamente una notifica Slack e le loro modifiche vengono registrate all’interno della user story.
Il tuo flusso di lavoro e la tua strategia di branching Git!
I flussi di lavoro Git che ho mostrato in questo articolo sono esempi di alcuni dei flussi di lavoro popolari e migliori per il team di sviluppo. Alcuni team creano un ramo per Staging e funziona perfettamente per loro.
Se usate altri flussi di lavoro che funzionano bene per voi, twittateci @getzepel. Ci piacerebbe mostrarli!
Articoli utili
Vikash KoushikThe Zepel Blog 
Ranjali RoyThe Zepel Blog 
Ranjali RoyThe Zepel Blog 