Lavoro di squadra senza confusione: comprensione delle strategie di ramificazione in Git

introduzione

Git è diventato lo standard de facto del settore per i sistemi di controllo della versione nello sviluppo del software. Dovresti prima leggere il mio articolo su cos'è Git e su come iniziare. Lo hai letto? Ottimo, andiamo! Piaccia o no, questo strumento creato da Linus Tovalds non andrà in pensione. Quindi, ha senso parlare di come i team distribuiti lavorano con Git e quale strategia di ramificazione dovrebbero scegliere per questo. Questa non è una domanda irrilevante. Quando si assembla un nuovo team di sviluppo che non ha mai lavorato insieme in precedenza, la strategia di ramificazione è spesso una delle prime cose da decidere. E alcune persone avranno la bava alla bocca per dimostrare che una strategia è migliore di un'altra. Quindi, voglio trasmetterti alcune informazioni generali su di loro.

Sono necessarie strategie di ramificazione?

Sono davvero necessari. Molto necessario. Perché se il team non è d'accordo su qualcosa, allora ogni membro del team farà quello che vuole:

• lavorando in qualsiasi ramo
• fusione in altri rami arbitrari
• eliminando alcuni rami
• creandone di nuovi
• e così ogni membro del team agirà in un flusso non gestito.

Ecco perché abbiamo tre strategie da considerare di seguito. Andiamo!

Flusso GitHub

Questa strategia di ramificazione, stranamente, è preferita su GitHub :) Viene fornita con una serie di regole :

1. Il codice nel ramo principale non deve essere violato. Dovrebbe essere pronto per essere distribuito in qualsiasi momento. Cioè, non devi inserire codice lì che ti impedirà di costruire il progetto e distribuirlo sul server.
2. Quando prevedi di lavorare su nuove funzionalità, devi creare un nuovo feature branch basato sul master branch e dargli un nome significativo. Esegui il commit del codice in locale e invia regolarmente le modifiche allo stesso ramo nel repository remoto.
3. Apri una richiesta pull (puoi leggere le richieste pull qui ) quando pensi che il lavoro sia pronto e possa essere unito al ramo master (o se non sei sicuro, ma vuoi avere un feedback sul lavoro svolto).
4. Dopo che la nuova funzionalità nella richiesta pull è stata approvata, può essere unita al ramo principale.
5. Quando le modifiche vengono unite nel ramo principale, devono essere distribuite immediatamente al server.

Secondo GitHub Flow, prima di iniziare a lavorare su qualcosa di nuovo, che si tratti di una correzione o di una nuova funzionalità, è necessario creare un nuovo ramo basato su master e dargli un nome adatto. Successivamente, inizia il lavoro sull'implementazione. Dovresti inviare costantemente commit al server remoto con lo stesso nome. Quando concludi che tutto è pronto, devi creare una richiesta pull al ramo principale. Quindi almeno una, o meglio ancora, due persone dovrebbero guardare questo codice prima di fare clic su "Approva". Di solito, il team leader del progetto e una seconda persona dovrebbero assolutamente dare un'occhiata. Quindi puoi completare la richiesta pull. GitHub Flow è noto anche per guidare la consegna continua (CD) nei progetti. Questo perché quando le modifiche entrano nel ramo principale, dovrebbero essere distribuite immediatamente al server.

GitFlow

La strategia precedente (GitHub Flow) non è molto complicata al suo interno. Esistono due tipi di branch: master e feature branch. Ma GitFlow è più serio. Almeno, l'immagine qui sopra dovrebbe chiarirlo :) Quindi, come funziona questa strategia? In generale, GitFlow è costituito da due rami persistenti e diversi tipi di rami temporanei. Nel contesto di GitHub Flow, il ramo master è persistente e gli altri sono temporanei. Rami persistenti

• maestro: Nessuno dovrebbe toccare o spingere qualcosa su questo ramo. In questa strategia, master rappresenta l'ultima versione stabile, che viene utilizzata in produzione (ovvero su un server reale)
• sviluppo: il ramo dello sviluppo. Potrebbe essere instabile.

Lo sviluppo avviene utilizzando tre rami temporanei ausiliari :

1. Feature branch — per lo sviluppo di nuove funzionalità.
2. Rami di rilascio — per preparare il rilascio di una nuova versione del progetto.
3. Rami hotfix: per correggere rapidamente un bug trovato da utenti reali su un server reale.

Caratteristica rami

I rami delle funzionalità vengono creati dagli sviluppatori per nuove funzionalità. Dovrebbero essere sempre creati in base al ramo di sviluppo. Dopo aver completato il lavoro sulla nuova funzionalità, è necessario creare una richiesta pull al ramo di sviluppo. Chiaramente, i team di grandi dimensioni possono avere più di un feature branch alla volta. Dai un'altra occhiata all'immagine all'inizio della descrizione della strategia GitFlow.

Rilascia i rami

Quando il set richiesto di nuove funzionalità è pronto nel ramo di sviluppo, puoi prepararti per il rilascio di una nuova versione del prodotto. Un ramo di rilascio, che viene creato in base al ramo di sviluppo, ci aiuterà in questo. Quando lavori con il ramo di rilascio, devi trovare e correggere tutti i bug. Anche tutte le nuove modifiche necessarie per stabilizzare il ramo di rilascio devono essere riunite nel ramo di sviluppo. Questo viene fatto per stabilizzare anche il ramo di sviluppo. Quando i tester affermano che il ramo è abbastanza stabile per una nuova versione, viene unito al ramo principale. Successivamente viene creato un tag, a cui viene assegnato un numero di versione, per questo commit. Per vedere un esempio, guarda l'immagine all'inizio della strategia. Lì vedrai Tag 1.0— questo è solo un tag che indica la versione 1.0 del progetto. E infine, abbiamo il ramo hotfix.

Rami hotfix

I rami hotfix servono anche per rilasciare una nuova versione al ramo master. L'unica differenza è che questi rilasci non sono pianificati. Ci sono situazioni in cui i bug entrano nella versione rilasciata e vengono scoperti nell'ambiente di produzione. Prendi iOS: non appena viene rilasciata una nuova versione, ricevi immediatamente una serie di aggiornamenti con correzioni per i bug rilevati dopo il rilascio. Di conseguenza, dobbiamo correggere rapidamente un bug e rilasciare una nuova versione. Nella nostra immagine corrisponde alla versione 1.0.1. L'idea è che il lavoro su nuove funzionalità non debba interrompersi quando è necessario correggere un bug su un server reale (o come si dice, "in prod" o "in produzione"). Il ramo hotfix deve essere creato dal ramo master, poiché rappresenta ciò che è attualmente in esecuzione in produzione. Non appena la correzione del bug è pronta, viene unito a master e viene creato un nuovo tag. Proprio come preparare un ramo di rilascio, anche un ramo di aggiornamento rapido dovrebbe unire la sua correzione nel ramo di sviluppo.

Flusso di lavoro di biforcazione

Nel flusso di lavoro del fork, lo sviluppo coinvolge due repository:

1. Il repository originale, in cui verranno unite tutte le modifiche.
2. Un archivio fork. Questa è una copia del repository originale, di proprietà di un altro sviluppatore che desidera apportare modifiche all'originale.

Suona un po' strano finora, vero? Chiunque abbia già incontrato lo sviluppo open source conosce già questo approccio. Questa strategia offre il seguente vantaggio: lo sviluppo può avvenire in un repository fork senza concedere le autorizzazioni per lo sviluppo congiunto nel ramo originale. Naturalmente, il proprietario del repository originale ha il diritto di rifiutare le modifiche proposte. O per accettarli e unirli. Questo è conveniente sia per il proprietario del repository originale che per lo sviluppatore che vuole aiutare a creare il prodotto. Ad esempio, puoi suggerire modifiche al kernel Linux . Se Linus decide che hanno senso, le modifiche verranno aggiunte (!!!).

Un esempio del flusso di lavoro di fork

Il flusso di lavoro di fork viene applicato su GitHub quando è presente una libreria che si desidera utilizzare. Ha un bug che ti impedisce di usarlo completamente. Supponi di immergerti abbastanza in profondità nel problema e di conoscere la soluzione. Utilizzando il flusso di lavoro di fork, puoi risolvere il problema senza i diritti per lavorare nel repository originale della libreria. Per iniziare, devi selezionare alcuni repository, ad esempio Spring Framework . Trova e fai clic sul pulsante "Fork" nell'angolo in alto a destra: ci vorrà del tempo. Quindi una copia del repository originale apparirà nel tuo account personale, che indicherà che si tratta di un fork:Ora puoi lavorare con questo repository come al solito, aggiungendo modifiche al ramo master e, quando tutto è pronto, puoi creare una richiesta pull al repository originale. Per fare ciò, fai clic sul pulsante Nuova richiesta pull :

Quale strategia scegliere

Git è uno strumento flessibile e potente che ti consente di lavorare utilizzando un'ampia varietà di processi e strategie. Ma più scelte hai, più difficile è decidere quale strategia scegliere. È chiaro che non esiste una risposta unica per tutti. Tutto dipende dalla situazione. Detto questo, ci sono diverse linee guida che possono aiutare in questo:

1. È meglio scegliere prima la strategia più semplice. Passa a strategie più complesse solo quando necessario.
2. Prendi in considerazione le strategie che hanno il minor numero possibile di tipi di branch per gli sviluppatori.
3. Guarda i pro e i contro delle varie strategie, quindi scegli quella che ti serve per il tuo progetto.

Questo è tutto ciò che volevo dire sulle strategie di ramificazione in Git. Grazie per l'attenzione :) Seguimi su GitHub , dove pubblico spesso le mie creazioni che coinvolgono diverse tecnologie e strumenti che utilizzo nel mio lavoro.