Adottare una strategia di creazione di rami 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.
• Mantenere un ramo principale di alta qualità e aggiornato.

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

Sviluppare le funzionalità e correggere i bug nei rami delle funzionalità in base al ramo principale. Questi rami sono noti anche come rami di argomento. 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. Esaminare i commit eseguiti nel ramo ed esaminare la richiesta pull che ha unito il ramo.

Assegnare un nome ai rami di 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à:

• users/username/description
• users/username/workitem
• bugfix/description
• feature/feature-name
• feature/feature-area/feature-name
• hotfix/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

Altre informazioni sull'uso dei flag di funzionalità nel codice.

Esaminare e unire codice con richieste pull

La revisione eseguita in una richiesta pull è fondamentale per migliorare la qualità del codice. Unire rami solo tramite richieste pull che superano il processo di revisione. Evitare di unire rami al ramo main senza una richiesta pull.

Il completamento delle revisioni nelle richieste pull richiede tempo. Il team deve essere d'accordo 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 sono 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 velocizzare i revisori con le modifiche.
• Includere una versione di compilazione o collegata delle modifiche in esecuzione in un ambiente a fasi con la richiesta pull. Altri utenti possono testare facilmente le modifiche.

Mantenere un ramo principale di alta qualità e aggiornato

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 criterio 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 compilazione riuscita per completare una richiesta pull. 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 completare, quindi non interferisce con il processo di revisione.

Gestire le versioni

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 ramo di rilascio dal ramo main quando si avvicina alla versione o a un'altra attività cardine, ad esempio la fine 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

Assicurarsi che le correzioni vengano risolte 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. Altre informazioni sulla strategia del flusso di rilascio sono disponibili.

In questo argomento verranno illustrate le modifiche apportate al ramo di rilascio e la conversione in mainline. Usare cherry-pick invece di unire 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.

Aggiornare il ramo main con una modifica apportata nel ramo di versione con questi passaggi:

1. Creare una nuova funzionalità diramazione dal ramo principale per convertire le modifiche.
2. Cherry-pick le modifiche dal ramo di rilascio al nuovo ramo di funzionalità.
3. Unire di nuovo il ramo di funzionalità nel ramo main in una seconda richiesta pull.

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 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 lo sviluppatore successivo che lavora da una versione precedente del codice durante il supporto della versione.

La strategia del ramo di rilascio estende il flusso di lavoro del ramo di funzionalità di base per gestire le versioni. Il team non deve adottare alcun nuovo processo di controllo della versione diverso da cherry-pick per convertire 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 deploy/performance-test, e trattare i rami dell'ambiente come i rami di rilascio. Il team deve accettare un processo per aggiornare i rami di distribuzione con il codice del ramo principale. Correzioni di bug cherry-pick nel ramo di distribuzione al ramo principale. Usare gli stessi passaggi della conversione delle modifiche da un ramo di versione.

Un'eccezione a questa raccomandazione è se si usa una forma di distribuzione continua. Usare Azure Pipelines quando si usa la distribuzione continua per promuovere le compilazioni dal ramo principale alle destinazioni di distribuzione.