Adottare una strategia di diramazione Git

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

I sistemi di controllo della versione distribuita come Git offrono flessibilità nel modo in cui si usa il controllo della versione per condividere e gestire il codice. Il team deve trovare un equilibrio tra questa flessibilità e la necessità di collaborare e condividere il codice in modo coerente.

I membri del team pubblicano, condividono, esaminano ed enumerare le modifiche al codice tramite rami Git condivisi con altri utenti. Adottare una strategia di diramazione per il team. È possibile collaborare meglio e dedicare meno tempo a gestire il controllo della versione e più tempo a sviluppare codice.

Le strategie di diramazione seguenti si basano sul modo in cui si usa Git qui in Microsoft. Per altre informazioni, vedere Come si usa Git in Microsoft.

Mantenere semplice la strategia del ramo

Mantenere semplice la strategia del ramo. Creare la strategia da questi tre concetti:

• Usare i rami feature per tutte le nuove funzionalità e le correzioni di bug.
• Unire rami di funzionalità nel ramo principale usando le richieste pull.
• Mantieni un ramo principale aggiornato e di alta qualità up-to.

Una strategia che estende questi concetti ed evita contraddizioni comporterà un flusso di lavoro di controllo della versione per il team coerente e facile da seguire.

Usare i rami di funzionalità per il lavoro

Sviluppa le tue funzionalità e correggi i bug nei branch di funzionalità basati sul tuo ramo principale. Questi rami sono anche conosciuti come rami tematici . I rami di funzionalità isolano il lavoro in corso dal lavoro completato nel ramo principale. I rami Git sono poco costosi da creare e gestire. Anche piccole correzioni e modifiche devono avere un proprio ramo di funzionalità.

La creazione di rami di funzionalità per tutte le modifiche semplifica la revisione della cronologia. Controlla i commit fatti nel ramo e guarda alla pull request che ha fuso il ramo.

Assegnare un nome ai rami delle funzionalità per convenzione

Usare una convenzione di denominazione coerente per i rami di funzionalità per identificare il lavoro svolto nel ramo. È anche possibile includere altre informazioni nel nome del ramo, ad esempio chi ha creato il ramo.

Alcuni suggerimenti per la denominazione dei rami di funzionalità:

• utenti/nome_utente/descrizione
• utenti/nomeutente/elementodilavoro
• Correzione bug/descrizione
• feature/feature-name
• caratteristica/area-caratteristica/nome-caratteristica
• correzione rapida/descrizione

Nota

Per informazioni sull'impostazione dei criteri per applicare una strategia di denominazione dei rami, vedere Richiedere cartelle di rami.

Usare i flag di funzionalità per gestire rami a esecuzione prolungata

Scopri di più su utilizzando i flag di funzionalità nel tuo codice.

Esaminare e unire il codice con pull request.

La revisione eseguita in una richiesta pull è fondamentale per migliorare la qualità del codice. Unisci i rami solo tramite richieste pull che abbiano superato il tuo processo di revisione. Evitare di fondere i rami nel ramo main senza un pull request.

Il completamento delle revisioni nelle richieste pull richiede tempo. Il tuo team dovrebbe concordare su ciò che ci si aspetta dai creatori di richieste pull e dai revisori. Distribuire le responsabilità dei revisori per condividere idee in tutto il team e diffondere le conoscenze della codebase.

Alcuni suggerimenti per le richieste pull riuscite:

• Due revisori è un numero ottimale basato sulla ricerca.
• Se il team ha già un processo di revisione del codice, inserire le richieste pull nelle operazioni già eseguite.
• Prestare attenzione all'assegnazione degli stessi revisori a un numero elevato di richieste pull. Le richieste pull funzionano meglio quando le responsabilità dei revisori vengono condivise tra il team.
• Fornire dettagli sufficienti nella descrizione per aggiornare rapidamente i revisori sulle modifiche.
• Includere una build o una versione collegata delle modifiche in esecuzione in un ambiente di staging con la richiesta pull. Altri utenti possono testare facilmente le modifiche.

Mantenere una qualità elevata, up-to-date ramo principale

Il codice nel ramo principale deve superare i test, compilare in modo pulito e essere sempre aggiornato. Il ramo principale necessita di queste qualità in modo che i rami di funzionalità creati dal team inizino da una versione valida nota del codice.

Configurare un di criteri di ramo per il ramo principale che:

• Richiede una richiesta pull per unire il codice. Questo approccio impedisce il push diretto al ramo principale e garantisce la discussione delle modifiche proposte.
• Aggiunge automaticamente revisori quando viene creata una richiesta pull. I membri del team aggiunti esaminano il codice e commentano le modifiche nella richiesta pull.
• Richiede una build riuscita per completare una pull request. Il codice unito al ramo principale deve essere compilato in modo pulito.

Suggerimento

La pipeline di compilazione per le richieste pull deve essere rapida da portare a termine, così da non interferire con il processo di revisione.

Gestire i rilasci

Usare i rami di rilascio per coordinare e stabilizzare le modifiche in una versione del codice. Questo ramo è di lunga durata e non viene unito di nuovo nel ramo principale in una richiesta pull, a differenza dei rami di funzionalità. Creare tutti i rami di rilascio necessari. Tenere presente che ogni ramo di rilascio attivo rappresenta un'altra versione del codice che è necessario supportare. Bloccare i rami di rilascio quando si è pronti per interrompere il supporto di una versione specifica.

Usare i rami di rilascio

Creare un branch di rilascio dal branch main quando ci si avvicina al momento del rilascio o a un altro traguardo, ad esempio la conclusione di uno sprint. Assegnare a questo ramo un nome chiaro associandolo alla versione, ad esempio versione/20.

Creare rami per correggere i bug dal ramo di rilascio e unirli di nuovo nel ramo di rilascio in una richiesta pull.

Modifiche delle porte al ramo principale

Assicuratevi che le correzioni siano applicate sia nel ramo di rilascio che nel ramo principale. Un approccio consiste nell'apportare correzioni nel ramo di rilascio, quindi apportare modifiche al ramo principale per impedire la regressione nel codice. Un altro approccio (e quello usato dal team di Azure DevOps) consiste nell'apportare sempre modifiche nella riga principale, quindi convertirli nel ramo di rilascio. Potete leggere di più sulla nostra strategia del flusso di rilascio .

In questo argomento, tratteremo come apportare modifiche al ramo di rilascio e trasferirle nella linea principale. Usare cherry-picking invece di fusione in modo da avere il controllo esatto su quali commit vengono trasferiti al ramo principale. L'unione del ramo di rilascio nel ramo principale può comportare modifiche specifiche della versione non desiderate nel ramo principale.

Aggiorna il branch principale con le modifiche apportate nel branch di rilascio seguendo questi passaggi:

1. Crea un nuovo ramo di funzionalità a partire dal ramo principale per trasferire le modifiche.
2. Seleziona attentamente le modifiche dal branch di rilascio per il tuo nuovo branch di funzionalità.
3. Fondere nuovamente il ramo di funzionalità nel ramo main in una seconda pull request.

Questo flusso di lavoro del ramo di rilascio mantiene intatti i pilastri del flusso di lavoro di base: rami di funzionalità, richieste pull e un ramo principale avanzato che ha sempre la versione più recente del codice.

Perché non usare i tag per le versioni?

Altri flussi di lavoro di diramazione usano i tag git per contrassegnare un commit specifico come versione. I tag sono utili per contrassegnare i punti nella cronologia come importanti. I tag introducono passaggi aggiuntivi nel flusso di lavoro che non sono necessari se si usano rami per le versioni.

I tag vengono mantenuti e inseriti separatamente dai commit. I membri del team possono facilmente perdere l'assegnazione di tag a un commit e quindi dover tornare indietro nella cronologia in seguito per correggere il tag. È anche possibile dimenticare il passaggio aggiuntivo per eseguire il push del tag, lasciando il successivo sviluppatore a lavorare da una versione precedente del codice durante il supporto al rilascio.

La strategia del ramo di rilascio estende il flusso di lavoro del ramo di funzionalità di base per gestire le versioni. Il tuo team non deve adottare alcun nuovo processo di controllo della versione diverso dal cherry-pick per applicare le modifiche.

Gestire le distribuzioni

È possibile gestire più distribuzioni del codice nello stesso modo in cui si gestiscono più versioni. Creare una convenzione di denominazione chiara, ad esempio distribuire/testare le prestazionie trattare i rami di ambiente come i rami di rilascio. Il tuo team dovrebbe concordare un processo per aggiornare i rami di distribuzione con il codice del ramo principale. Selezionare le correzioni di bug nel ramo di distribuzione per riportarle al ramo principale. Usare gli stessi passaggi del trasferimento delle modifiche da un ramo di rilascio.

Un'eccezione a questa raccomandazione è se si usa una forma di distribuzione continua. Usare Azure Pipelines nella distribuzione continua per promuovere i build dal ramo principale alle destinazioni di distribuzione.