Lavoro di squadra senza confusione: comprendere le strategie di ramificazione in Git

introduzione

Git è diventato di fatto lo standard industriale per il controllo della versione nella creazione di software. Per sapere cos'è Git e come iniziare, leggi prima il mio articolo a riguardo. Lo hai letto? Ottimo, andiamo avanti! Piaccia o no, lo strumento creato da Linus Towalds non andrà in pensione. Pertanto, ha senso parlare di come lavorano i team distribuiti in Git e di quale strategia di ramificazione scegliere per questo. E questa non è affatto una domanda inutile. Spesso, in una situazione in cui si riunisce un nuovo team di sviluppatori che non hanno collaborato tra loro, la strategia di ramificazione è una delle prime cose da decidere. E ci saranno persone con la schiuma alla bocca per dimostrare che una strategia è migliore di un'altra. Pertanto, voglio trasmetterti informazioni su cosa sono generalmente.

Sono necessarie strategie di ramificazione?

Ma sono necessari e sono ancora necessari. Perché se non sei d'accordo su qualcosa nella squadra, ognuno farà quello che vuole:

• lavorare nel ramo in cui vuole;
• fondersi in altri rami che desidera;
• eliminare alcuni rami;
• crearne di nuovi;
• e così via: ciascuno dei membri del team si trova in un flusso incontrollato.

Pertanto, di seguito sono riportate tre strategie. Andare!

Strategia del flusso GitHub

La strategia di ramificazione, non importa quanto strana possa essere, è preferita in GitHub :) In allegato c'è una serie di regole che devono essere seguite:

1. Il codice nel ramo master deve essere ininterrotto e pronto per essere distribuito in qualsiasi momento (ovvero, non è possibile inserire lì codice che impedisca di creare il progetto e distribuirlo sul server).
2. Quando prevedi di lavorare su una nuova funzionalità, devi creare un nuovo ramo (ramo funzionalità) basato sul ramo principale e dargli un nome significativo. Applica il tuo codice localmente e invia regolarmente le modifiche allo stesso ramo in un repository remoto.
3. Apri una Pull-Request (puoi leggere cos'è una pull-request qui ) quando c'è la chiara sensazione che il lavoro è pronto e può essere accorpato nel ramo master (o se non sei sicuro, ma vuoi avere un feedback su il lavoro svolto).
4. Dopo che una nuova funzionalità in una richiesta pull è stata approvata, può essere unita al ramo principale.
5. Quando le modifiche vengono unite nel ramo master, devono essere distribuite immediatamente al server.

Secondo GitHub Flow, risulta che 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, iniziano i lavori sull'implementazione. È necessario inviare costantemente i commit a un server remoto con lo stesso nome. Quando capisci che tutto è pronto, devi creare una richiesta pull nel ramo principale. Quindi almeno una, o meglio ancora, due persone dovrebbero guardare questo codice e fare clic su Approva. Di solito, il team leader del progetto e qualcun altro devono esaminarlo, quindi è possibile completare la richiesta pull. GitHub Flow è noto anche per guidare la consegna continua (CD) su un progetto. Perché quando vengono apportate modifiche al ramo principale, devono essere immediatamente distribuite al server.

Strategia GitFlow

La strategia precedente (GitHub Flow) non era sostanzialmente molto complessa. Esistono due tipi di rami: rami master e rami funzionalità. Ma GitFlow è più serio. Almeno dall'immagine sopra puoi capirlo) Quindi, come funziona questa strategia? In generale, GitFlow è costituito da due rami permanenti e diversi tipi di rami temporanei (nel contesto di GitHub Flow, il ramo master è permanente e gli altri sono temporanei). Rami permanenti:

• maestro: nessuno deve toccare questo ramo o spingere lì qualcosa. In questa strategia, master visualizza l'ultima versione stabile utilizzata in produzione (ovvero sul real server);
• lo sviluppo è il ramo dello sviluppo. Potrebbe essere potenzialmente instabile.

Lo sviluppo viene effettuato utilizzando tre rami temporanei ausiliari :

1. Rami di funzionalità: per lo sviluppo di nuove funzionalità.
2. Rami di rilascio: per prepararsi al rilascio di una nuova versione del progetto.
3. I rami Hotfix sono una soluzione rapida a un difetto già riscontrato da utenti reali su un server reale.

Rami di funzionalità

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 nel ramo di sviluppo. È chiaro che nei team di grandi dimensioni possono esserci più rami di funzionalità alla volta. Ancora una volta, presta attenzione all'immagine all'inizio della descrizione della strategia GitFlow.

Rilascia i rami

Una volta preparato il numero richiesto di nuove funzionalità nel ramo di sviluppo, è possibile prepararsi a rilasciare una nuova versione del prodotto. Il ramo di rilascio ci aiuterà in questo. che viene creato in base al ramo di sviluppo. Mentre lavori con il ramo di rilascio, devi trovare e correggere tutti i difetti. Anche eventuali nuove modifiche necessarie per stabilizzare il ramo di rilascio devono essere reintegrate nello sviluppo. Questo viene fatto per stabilizzare e sviluppare il ramo. Quando i tester dicono che il ramo è sufficientemente stabile per una nuova release, viene unito al ramo master. Successivamente, viene creato un tag su questo commit (tag: puoi leggere di più a riguardo qui ), a cui viene assegnato un numero di versione. Ad esempio, puoi guardare l'immagine all'inizio della strategia. Quindi il Tag 1.0 è solo un'etichetta che indica la versione 1.0 del progetto. E l'ultima cosa è un hotfix del ramo.

Rami dell'aggiornamento rapido

I rami Hotfix sono previsti anche per il rilascio di una nuova versione in master. L'unica differenza è che questa versione non è pianificata. Ci sono situazioni in cui i difetti vengono rilasciati e sono già scoperti in produzione. Ad esempio, iOS: non appena rilasciano una nuova versione, ricevi immediatamente una serie di aggiornamenti con correzioni per i difetti scoperti dopo il rilascio. A questo proposito, è necessario correggere rapidamente questo difetto e rilasciare una nuova versione. Nella nostra immagine questo corrisponde alla versione 1.0.1. L'idea è che il lavoro su nuove funzionalità potrebbe non fermarsi nei momenti in cui è necessario correggere un difetto su un server reale (come diciamo, “in produzione”: ancora una volta, una copia della parola inglese production). Il ramo hotfix deve essere creato dal ramo master, poiché rappresenta lo stato che funziona in produzione. Non appena la soluzione al difetto è pronta, viene unita al master e viene creata una nuova etichetta. Proprio come preparare un ramo di rilascio, un ramo di hotfix dovrebbe unire la propria soluzione nel ramo di sviluppo.

La strategia del flusso di lavoro di fork

Nell'ambito della strategia Forking Workflow, lo sviluppo viene effettuato in modo tale che siano presenti due repository:

1. Il repository originale in cui verranno unite tutte le modifiche.
2. Un repository fork (si tratta di una copia del repository originale in possesso di un altro sviluppatore che desidera apportare modifiche all'originale).

Sembra un po' strano finora, vero? Per coloro che hanno già incontrato lo sviluppo open source, questo approccio è già familiare. Questa strategia offre il seguente vantaggio: lo sviluppo può essere effettuato in un repository fork senza garantire i diritti di sviluppo congiunto in quello originale. Naturalmente, il proprietario del repository originale ha il diritto di rifiutare le modifiche proposte. Oppure accetta e uccidili. Ciò è conveniente sia per il proprietario del repository originale che per lo sviluppatore che desidera partecipare alla creazione di un prodotto. Ad esempio, puoi proporre modifiche al kernel Linux . Se Linus decide che hanno senso, i cambiamenti verranno aggiunti (!!!).

L'esempio del flusso di lavoro con biforcazione

Il Forking Flow viene utilizzato su GitHub quando è presente una libreria che desideri utilizzare. Ha un difetto che ne impedisce l'utilizzo completo. Diciamo che hai approfondito abbastanza il problema e conosci la soluzione. Utilizzando la strategia del Forking Workflow, puoi risolvere questo problema senza concedere i diritti per lavorare nel repository della libreria originale. Per iniziare, devi selezionare un repository, ad esempio Spring Framework core . Trova il pulsante Fork nell'angolo in alto a destra e fai clic su di esso: ci vorrà del tempo, dopodiché una copia di questo repository originale apparirà nel tuo account personale, che indicherà che si tratta di un fork: quindi puoi lavorare con questo repository come al solito, aggiungere modifiche al ramo master e quando tutto è pronto, creare una Pull-Request nel repository originale. Per fare ciò, fare clic sul pulsante Nuova richiesta pull :

Quale strategia scegliere

Git è uno strumento flessibile e potente che ti consente di lavorare utilizzando un'ampia gamma di processi e strategie. Ma maggiore è la scelta, più difficile sarà decidere quale strategia adottare adesso. Chiaramente non esiste una risposta valida per tutti. Tutto dipende dalla situazione. Tuttavia, ci sono alcuni consigli che possono aiutare in questo:

1. È meglio scegliere prima la strategia più semplice. Passare a strategie più complesse solo quando necessario.
2. Considera strategie che abbiano il minor numero possibile di rami di sviluppo.
3. Guarda i pro e i contro delle diverse strategie e, in base al progetto, scegli quella giusta.

Questo è tutto ciò che volevo dirti sulla strategia di ramificazione in git. Grazie per l'attenzione :) Iscriviti al mio account GitHub , spesso pubblico lì il mio lavoro in varie tecnologie e strumenti che utilizzo nel mio lavoro

link utili

• Flusso GitHub: il modo migliore per utilizzare Git e GitHub
• Invia richieste su GitHub o Come posso apportare modifiche al progetto di qualcun altro
• GitHub: informazioni sulle richieste pull
• Integrazione continua, distribuzione e distribuzione differenziata
• Nozioni di base su Git: lavorare con i tag
• Habr: modello di ramificazione di successo per Git