Come scegliere il flusso di lavoro Git e il modello di ramificazione adatto al tuo team

Git è il sistema di controllo della versione al centro di quasi tutto lo sviluppo del software: viene utilizzato per archiviare e tenere traccia delle modifiche al codice che scrivi. Quando si lavora in un team, avere un flusso di lavoro senza interruzioni che funzioni per la tua azienda è fondamentale per crescere rapidamente.

Migliore organizzazione del repository, sviluppo più rapido

Con l’avvento di pipeline di automazione di facile utilizzo come Jenkins, molte aziende stanno iniziando a implementare l’integrazione e la distribuzione continue (CI/CD), con le modifiche degli sviluppatori che spesso vengono unite in un repository, distribuendo in genere il prodotto su base settimanale anziché su base settimanale. programma mensile.

Questa velocità mette a dura prova la tua organizzazione, specialmente quando si tratta di Git. Se sono presenti 50 persone che tentano di eseguire il commit delle modifiche allo stesso  master ramo, si verificheranno problemi con frequenti conflitti di unione.

Fortunatamente, Git offre la possibilità di creare rami e scegliere quando si desidera unire il codice, che ogni team dovrebbe utilizzare per organizzare il proprio sviluppo. Prendere il controllo del tuo flusso di lavoro Git salverà almeno te e i tuoi compagni di squadra dal perdere tempo a cercare su Google nuovi problemi di Git.

Caratteristiche e sviluppo delle filiali

Ci sono due grossi problemi su cui stanno lavorando i rami di Git: mantenere sincronizzati i comandi interni e mantenere la versione pubblica.

Quando avvii un ramo in Git, verranno effettuati nuovi commit su quel ramo, non master. Questo può essere utile per tenere traccia dei progressi individuali su una determinata funzionalità o correzioni di bug; ad esempio, ogni ramo può implementare una funzionalità descritta in un problema in un servizio Kanban come Jira, Trello o Github Issues & Projects.

L’unione di rami viene solitamente eseguita utilizzando richieste pull, una funzionalità delle soluzioni Git ospitate come Github in cui il comando richiede un master pull da feature un ramo e integra le modifiche per tutti. Questo può essere molto utile per i team che eseguono QA e unit test per assicurarsi che una filiale funzioni correttamente prima di salire nella catena.

Un altro problema è la gestione dei rilasci: non si desidera inviare ai clienti una copia dell’ultima build di sviluppo interna, poiché potrebbe essere danneggiata da un commit errato.

Per risolvere questo problema, molti team utilizzeranno un ramo separato per i rilasci e uniranno quel ramo solo quando è il momento di rilasciare una nuova versione. Ciò consente più commit in background sul ramo di sviluppo tra le versioni.

Un altro vantaggio di questo modello è la possibilità di eseguire commit separati sul ramo di produzione, fornendo eventualmente correzioni per problemi prima che la versione successiva sia pronta.

Sviluppo principale

La tua strategia di ramificazione determina esattamente come utilizzerai gli strumenti forniti. Esistono molte strategie di ramificazione diverse progettate per diversi tipi di team.

Lo sviluppo basato su autostrada è simile a quello che dovrebbe essere la programmazione in team: iterazione rapida in un master ramo per rilasciare rapidamente un prodotto valido. Il team crea rami di funzionalità di breve durata, che di solito non durano più di pochi giorni, e spesso si impegna direttamente in master.

Si chiama “tronco” perché master rende il ramo il ramo più attivo e utile dell’intero repository, come un grosso tronco d’albero che sostiene tutto il resto. Tutto lo sviluppo si concentra su questo ramo, che è facile e veloce da imparare, fornendo una buona esperienza di sviluppo.

Una volta pronto per il rilascio, viene creato un nuovo ramo con versione per ogni rilascio. Questo separa le versioni da mastere ti aiuta anche ad aggiungere o selezionare correzioni per le versioni LTS.

Questo ha molti vantaggi, soprattutto per i piccoli team. Se lavori con alcuni sviluppatori senior, conosci e ti fidi dei permessi di scrittura dell’intero repository, l’integrazione delle modifiche il prima possibile può davvero accelerare lo sviluppo. Alla fine, questo elimina quasi tutta la burocrazia associata alle continue richieste di pull e alle fusioni, sebbene sia comunque necessaria una semplice comunicazione con il tuo team per tenersi alle calcagna e dovresti sempre sapere su cosa sta lavorando l’altro.

Tuttavia, questa non è una buona organizzazione in quanto dipende dalla disciplina e da buoni sviluppatori. Questo è davvero ottimo per rilasciare rapidamente prodotti o iterare rapidamente su progetti esistenti, ma non appena aggiungi più sviluppatori junior al progetto o ottieni più collaboratori open source, inizia a mostrare i suoi difetti.

Flusso Git tradizionale

“Git Flow” è un flusso di lavoro che funziona in molti team. Questo è più complesso del semplice flusso di lavoro di sviluppo backbone, ma offre molti vantaggi per progetti open source e progetti di grandi dimensioni con molti membri del team.

Nella strategia di ramificazione di Git Flow, i rami di funzionalità durano più a lungo e sono l’obiettivo principale dell’integrazione quotidiana. I team lavoreranno sulle funzionalità fino a quando non saranno pronte per la produzione, quindi eseguiranno un processo di richiesta pull per ottenere la loro approvazione. Possono essere presenti un numero qualsiasi di funzionalità contemporaneamente, comprese quelle che durano abbastanza a lungo da dover essere ribasate su commit più recenti master .

Con Git Flow, l’accesso è più limitato, poiché la maggior parte degli sviluppatori non avrà il permesso di fondersi direttamente con develop, e certamente non con master, e dovrà creare branch come metodo principale per apportare modifiche.

Git Flow lascia naturalmente il tempo per una corretta revisione del codice durante il processo di richiesta pull. Ciò consente di gestire i conflitti con PR, rebase e unioni piuttosto che con un ramo backbone in continua evoluzione. Questo ha senso per l’open source perché questi fork possono provenire da terze parti, ma ha senso anche in ambienti di team di grandi dimensioni o per team che sviluppano prodotti monolitici con molti componenti.

Una delle caratteristiche chiave di questo flusso di lavoro è il modello di rilascio. Quando arriva il momento di una nuova versione, viene creato un ramo separato per la preparazione. Qui vengono apportate correzioni di bug e patch finali, quindi inserite nel master ramo reale e viene assegnato un tag da cui creare la versione.

La differenza fondamentale è che questo master ramo viene mantenuto insieme a develop. I commit dai rami di rilascio vengono nuovamente uniti in develop, così come eventuali correzioni. Questo crea sempre develop il ramo più recente da cui vengono effettuate le versioni quando sono stabili.

Questa separazione semplifica la gestione delle correzioni di bug minori che devono essere rilasciate prima che master vengano unite nelle versioni più recenti. Il ramo di rilascio funziona più o meno allo stesso modo del ramo di funzionalità, con il vantaggio aggiuntivo di essere contrassegnato come stabile.

Naturalmente, le continue richieste di pull, rebase e merge sono un duro lavoro e possono essere noiose se stai cercando di essere veloce. Ma proprio come la digitazione statica o gli unit test, vale la pena mantenere le cose organizzate e funzionare senza intoppi alla fine.

Scegli quello che fa per te

Alla fine, si tratta di una buona etichetta di squadra e la tua squadra può fare benissimo con una cronologia Git che è più simile a una linea che a un diagramma di fantasia. Se il tuo progetto è piccolo o sei un hobbista solista, attenersi a severi standard Git può farti più male che bene.

Ma se hai problemi con Git, puoi provare lo sviluppo backbone o Git Flow. Per lo meno, comprendere l’organizzazione del tuo repository ti aiuterà a migliorare il processo di integrazione.