Esplorare il modello di ramificazione Git per il recapito continuo

3 minuti

Lo scopo della scrittura di codice è quello di apportare miglioramenti al software.

Un modello di diramazione che introduce un eccessivo sovraccarico di processi non consente di aumentare la velocità con cui le modifiche raggiungono i clienti. Lo sviluppo di un modello di diramazione consente di offrire supporto sufficiente per non fornire modifiche di scarsa rilevanza. ma allo stesso tempo non introdurre troppi processi e causare rallentamenti.

Su Internet sono disponibili numerose strategie di ramificazione per Git. Non ne esistono di giuste o di sbagliate. La strategia di ramificazione perfetta è quella più adatta alle esigenze del team.

Si apprenderà come usare la combinazione di rami feature e richieste pull per avere un ramo main pronto per l'implementazione

Preparazione

Di seguito sono illustrati i principi su cui si basa il modello suggerito:

Il ramo main:
- Il ramo main è l'unico modo per rilasciare un artefatto nell'ambiente di produzione.
- Lo stato del ramo main deve essere sempre pronto per il rilascio.
- Proteggere questo ramo con criteri specifici.
- Il flusso delle modifiche al ramo main avviene solo tramite richieste pull.
- Contrassegnare tutte le versioni nel ramo main con tag Git.
Il ramo feature:
- Usare i rami feature per tutte le nuove funzionalità e le correzioni di bug.
- Usare i flag di funzionalità per gestire i rami feature a esecuzione prolungata.
- Il flusso delle modifiche dai rami feature al ramo main avviene solo tramite richieste pull.
- Assegnare un nome alla funzionalità in base allo scopo per cui viene usata.
Ramo di rilascio:
- Creare un ramo di rilascio dedicato da un ramo di funzionalità stabile per prepararsi alla distribuzione.
- Assicurarsi che il ramo di rilascio venga sottoposto a test e stabilizzazioni approfonditi.
- Applicare correzioni di bug e le modifiche necessarie al ramo di rilascio prima della distribuzione.
- Contrassegnare le versioni nel ramo di rilascio per evidenziare attività cardine significative.
Elenco dei rami:
```
bugfix/description
features/feature-name
features/feature-area/feature-name
hotfix/description
users/username/description
users/username/workitem
```
Richieste pull:
- Esaminare il codice ed eseguirne il merge con le richieste pull.
- Automatizzare l'ispezione e la convalida come parte delle richieste pull.
- Tenere traccia del tempo di completamento delle richieste pull e definire gli obiettivi per ridurre il tempo impiegato.

Si userà l'applicazione myWebApp creata negli esercizi precedenti. Vedere Descrivere l'uso di Git in locale.

In questa procedura si useranno tre estensioni molto diffuse che sono disponibili nel marketplace:

Interfaccia della riga di comando di Azure: è un'interfaccia della riga di comando per Azure.
Interfaccia della riga di comando di Azure DevOps: è un'estensione dell'interfaccia della riga di comando di Azure per l'uso di Azure DevOps e Azure DevOps Server progettata per l'integrazione senza problemi con Git, pipeline CI e strumenti Agile. Con l'interfaccia della riga di comando di Azure DevOps è possibile contribuire ai progetti senza lasciare la riga di comando. L'interfaccia della riga di comando viene eseguita in Windows, Linux e Mac.
Git Pull Request Merge Conflict: questa estensione open source creata da Microsoft DevLabs consente di esaminare e risolvere i conflitti di merge delle richieste pull sul Web. Prima di completare una richiesta pull Git, è necessario risolvere eventuali conflitti con il ramo di destinazione. Usando questa estensione è possibile risolvere questi conflitti sul Web come parte del merge delle richieste pull anziché eseguire il merge e risolvere i conflitti in un clone locale.

L'interfaccia della riga di comando di Azure DevOps supporta i risultati delle query in formato JSON, JSONC, YAML, YAMLC, tabella, TSV e nessun formato. È possibile configurare il formato preferito usando il comando configure.

Procedura

Importante

È necessario creare il progetto nel primo percorso di apprendimento: Descrivere l'uso di Git in locale.

Dopo aver clonato il ramo main in un repository locale, creare un nuovo ramo feature, myFeature-1:

myWebApp
```
git checkout -b feature/myFeature-1
```
Output:

Switched to a new branch 'feature/myFeature-1'.
Eseguire il comando del ramo Git per visualizzare tutti i rami. Il ramo visualizzato con un asterisco è il ramo "attualmente estratto":

myWebApp
```
git branch
```
Output:

feature/myFeature-1

main
Apportare una modifica al file Program.cs nel ramo feature/myFeature-1:

myWebApp
```
notepad Program.cs
```
Preparare per il commit le modifiche, eseguire il commit in locale e quindi pubblicare il ramo in remoto:

myWebApp
```
git status
```
Output:

On branch feature/myFeature-1 Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: Program.cs.

myWebApp
```
git add .
git commit -m "Feature 1 added to Program.cs"
```
Output:

[feature/myFeature-1 70f67b2] feature 1 added to program.cs 1 file changed, 1 insertion(+).

myWebApp
```
git push -u origin feature/myFeature-1
```
Output:

Delta compression using up to 8 threads. Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 348 bytes | 348.00 KiB/s, done. Total 3 (delta 2), reused 0 (delta 0) remote: Analyzing objects... (3/3) (10 ms) remote: Storing packfile... done (44 ms) remote: Storing index... done (62 ms) To https://dev.azure.com/organization/teamproject/\_git/MyWebApp * [new branch] feature/myFeature-1 -> feature/myFeature-1 Branch feature/myFeature-1 set up to track remote branch feature/myFeature-1 from origin.

Nell'ambiente remoto viene mostrata la cronologia delle modifiche:
Configurare l'interfaccia della riga di comando di Azure DevOps per l'organizzazione e il progetto. Sostituire organization e project name:
```
az devops configure --defaults organization=https://dev.azure.com/organization project="project name"
```
Creare una nuova richiesta pull (usando l'interfaccia della riga di comando di Azure DevOps) per esaminare le modifiche apportate al ramo feature-1:
```
az repos pr create --title "Review Feature-1 before merging to main" --work-items 38 39 `
--description "#Merge feature-1 to main" `
--source-branch feature/myFeature-1 --target-branch main `
--repository myWebApp --open
```
Quando si genera la richiesta pull, usare l'opzione --open per aprirla in un Web browser dopo che è stata creata. È possibile usare l'opzione --deletesource-branch per eliminare il ramo dopo il completamento della richiesta pull. È inoltre consigliabile usare --auto-complete per il completamento automatico quando tutti i criteri risultano soddisfatti ed è possibile eseguire il merge del ramo di origine con quello di destinazione.

Nota

Per altre informazioni sul parametro az repos pr create, vedere Creare una richiesta pull per esaminare e unire il codice.

Il team esamina collettivamente le modifiche apportate al codice e approva la richiesta pull:

Il ramo main è pronto per il rilascio. Il team contrassegna il ramo principale con il numero di versione:
Iniziare a lavorare su Feature 2. Creare un ramo in remoto a partire dal ramo main ed estrarlo in locale:

myWebApp
```
git push origin main:refs/heads/feature/myFeature-2
```
Output:

Total 0 (delta 0), reused 0 (delta 0) To https://dev.azure.com/**organization**/**teamproject**/\_git/MyWebApp * [new branch] origin/HEAD -> refs/heads/feature/myFeature-2.

myWebApp
```
git checkout feature/myFeature-2
```
Output:

Switched to a new branch 'feature/myFeature-2' Branch feature/myFeature-2 set up to track remote branch feature/myFeature-2 from origin.

In Program.cs modificare la stessa riga di commento nel codice modificata in feature-1.

public class Program
{
    // Editing the same line (file from feature-2 branch)
    public static void Main(string[] args)
    {
        BuildWebHost(args).Run();
    }

    public static IWebHost BuildWebHost(string[] args) =>
        WebHost.CreateDefaultBuilder(args)
            .UseStartup<Startup>()
            .Build();

Eseguire il commit delle modifiche in locale, eseguirne il push nel repository remoto e quindi generare una richiesta pull per eseguire il merge delle modifiche da feature/myFeature-2 al ramo main:
```
az repos pr create --title "Review Feature-2 before merging to main" --work-items 40 42 `
--description "#Merge feature-2 to main" `
--source-branch feature/myFeature-2 --target-branch main `
--repository myWebApp --open
```
Viene segnalato un bug critico nell'ambiente di produzione rispetto alla versione feature-1 con la richiesta pull in anteprima. Per analizzare il problema, è necessario eseguire il debug della versione del codice attualmente distribuita in produzione. Per analizzare il problema, creare un nuovo ramo fof usando il tag release_feature1:

myWebApp
```
git checkout -b fof/bug-1 release_feature1
```
Output:

Switched to a new branch, 'fof/bug-1'.

In Program.cs modificare la stessa riga di codice che è stata modificata nella versione feature-1.

public class Program
{
    // Editing the same line (file from feature-FOF branch)
    public static void Main(string[] args)
    {
        BuildWebHost(args).Run();
    }

    public static IWebHost BuildWebHost(string[] args) =>
        WebHost.CreateDefaultBuilder(args)
            .UseStartup<Startup>()
            .Build();

Preparare per il commit le modifiche, eseguire il commit in locale e quindi eseguire il push delle modifiche nel repository remoto:

myWebApp
```
git add .
git commit -m "Adding FOF changes."
git push -u origin fof/bug-1
```
Output:

To https://dev.azure.com/**organization**/**teamproject**/\_git/MyWebApp * [new branch] fof/bug-1 - fof/bug-1 Branch fof/bug-1 set up to track remote branch fof/bug-1 from origin.
Subito dopo l'implementazione delle modifiche nell'ambiente di produzione, contrassegnare il ramo fof\bug-1 con il tag release_bug-1, quindi generare una richiesta pull per eseguire nuovamente il merge delle modifiche di fof/bug-1 nel ramo main:
```
az repos pr create --title "Review Bug-1 before merging to main" --work-items 100 `
--description "#Merge Bug-1 to main" `
--source-branch fof/Bug-1 --target-branch main `
--repository myWebApp --open
```
Come parte della richiesta pull, il ramo viene eliminato. È comunque possibile fare riferimento all'intera cronologia usando il tag.

Una volta gestita la correzione del bug critico, rivedere la richiesta pull di feature-2.

Nella pagina Rami risulta evidente che il ramo feature/myFeature-2 ha una modifica in più e due modifiche in meno rispetto al ramo main:

Se si è tentato di approvare la richiesta pull, si dovrebbe vedere un messaggio di errore in cui viene segnalato un conflitto di merge:
L'estensione Git Pull Request Merge Conflict consente di risolvere i conflitti di merge direttamente nel browser. Passare alla scheda dei conflitti e fare clic su Program.cs per risolvere i conflitti di merge:

L'interfaccia utente consente di selezionare l'origine e la destinazione, di aggiungere modifiche personalizzate, rivedere e inviare il comando di merge. Una volta eseguito il merge delle modifiche, la richiesta pull è completata.

A questo punto, è possibile creare un ramo di rilascio basato sulla correzione di bug critica implementata nel ramo fof/bug-1 e unito al ramo principale. Usando il comando git checkout, creare un ramo di rilascio dedicato dal ramo principale.

git checkout -b release/v1.1 main

Questo comando crea un nuovo ramo denominato release/v1.1 basato sul ramo principale.

Man mano che vengono raggiunte attività cardine significative durante il processo di rilascio, contrassegnare le versioni nel ramo di rilascio usando tag Git. I tag fungono da marcatori per indicare versioni specifiche del software.

git tag -a v1.1 -m "Release version 1.1"

Questo comando crea un tag denominato v1.1 per contrassegnare la versione 1.1 nel ramo di rilascio.

Funzionamento

Si è appreso come il modello di ramificazione Git offre la flessibilità di lavorare su funzionalità in parallelo creando un ramo per ciascuna di esse.

Il flusso di lavoro delle richieste pull consente di esaminare le modifiche del codice usando i criteri dei rami.

I tag Git sono un ottimo modo per registrare le attività cardine, ad esempio la versione del codice rilasciata, e offrono anche la possibilità di creare rami.

In questa procedura è stato creato un ramo da un tag di versione precedente per correggere un bug critico nell'ambiente di produzione.

La visualizzazione dei rami nel portale Web consente di identificare più facilmente i rami con più modifiche rispetto al ramo main. Genera inoltre un conflitto di merge se eventuali richieste pull in corso tentano di eseguire il merge nel ramo main senza risolvere i conflitti.

Un modello di diramazione snello consente di creare rami di breve durata ed eseguire più velocemente il push di modifiche di qualità nell'ambiente di produzione.

Esplorare il modello di ramificazione Git per il recapito continuo

Preparazione

Procedura

Funzionamento

Commenti e suggerimenti