Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

# Filiali in una strategia Gitflow
<a name="branches-in-a-gitflow-strategy"></a>

Una strategia di ramificazione Gitflow ha in genere i seguenti rami.



![\[I rami e gli ambienti in una strategia di ramificazione Gitflow.\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/choosing-git-branch-approach/images/gitflow-branching-strategy.png)


## ramo di funzionalità
<a name="feature-branch"></a>

`Feature`le filiali sono filiali a breve termine in cui si sviluppano funzionalità. Il `feature` ramo viene creato dalla diramazione del `develop` ramo. Gli sviluppatori eseguono iterazioni, eseguono il commit e testano il `feature` codice nel ramo. Quando la funzionalità è completa, lo sviluppatore la promuove. Esistono solo due percorsi da seguire da un ramo di funzionalità:
+ Unisciti al ramo `sandbox`
+ Crea una richiesta di unione nel ramo `develop`


|  |  | 
| --- |--- |
| Convenzione di denominazione: | `feature/<story number>_<developer initials>_<descriptor>` | 
| Esempio di convenzione di denominazione: | `feature/123456_MS_Implement_Feature_A` | 

## ramo sandbox
<a name="sandbox-branch"></a>

Il `sandbox` ramo è un ramo non standard a breve termine per Gitflow. Tuttavia, è utile per CI/CD lo sviluppo di pipeline. La `sandbox` filiale viene utilizzata principalmente per i seguenti scopi:
+ Esegui una distribuzione completa nell'ambiente sandbox utilizzando le CI/CD pipeline anziché una distribuzione manuale.
+ Sviluppa e testa una pipeline prima di inviare richieste di unione per il test completo in un ambiente inferiore, ad esempio sviluppo o test.

`Sandbox`le filiali sono di natura temporanea e non sono destinate a durare a lungo. Dovrebbero essere cancellate dopo il completamento del test specifico.


|  |  | 
| --- |--- |
| Convenzione di denominazione: | `sandbox/<story number>_<developer initials>_<descriptor>` | 
| Esempio di convenzione di denominazione: | `sandbox/123456_MS_Test_Pipeline_Deploy` | 

## sviluppare un ramo
<a name="develop-branch"></a>

La `develop` filiale è una filiale longeva in cui le funzionalità vengono integrate, create, convalidate e implementate nell'ambiente di sviluppo. Tutte le `feature` filiali vengono unite nella filiale. `develop` Le fusioni nel `develop` ramo vengono completate tramite una richiesta di unione che richiede una build corretta e due approvazioni da parte degli sviluppatori. Per impedire l'eliminazione, abilita la protezione del ramo sul ramo. `develop`


|  |  | 
| --- |--- |
| Convenzione di denominazione: | `develop` | 

## ramo di rilascio
<a name="release-branch"></a>

In Gitflow, le `release` filiali sono filiali a breve termine. Queste filiali sono speciali perché puoi distribuirle in più ambienti, adottando la metodologia build-once, deploy-many. `Release`le filiali possono rivolgersi agli ambienti di test, staging o produzione. Dopo che un team di sviluppo ha deciso di promuovere le funzionalità in ambienti superiori, crea una nuova `release` filiale e utilizza l'incremento del numero di versione rispetto alla versione precedente. Ai gate di ogni ambiente, le implementazioni richiedono approvazioni manuali per procedere. `Release`le filiali devono richiedere la modifica di una richiesta di unione.

Una volta che la `release` filiale è entrata in produzione, dovrebbe essere ricongiunta ai `main` rami `develop` and per assicurarsi che eventuali correzioni di bug o hotfix vengano reintegrati nelle attività di sviluppo future.


|  |  | 
| --- |--- |
| Convenzione di denominazione: | `release/v{major}.{minor}` | 
| Esempio di convenzione di denominazione: | `release/v1.0` | 

## ramo principale
<a name="main-branch"></a>

Il `main` ramo è un ramo longevo che rappresenta sempre il codice in esecuzione in produzione. Il codice viene unito automaticamente al `main` ramo da un ramo di rilascio dopo una corretta distribuzione dalla pipeline di rilascio. Per impedire l'eliminazione, abilita la protezione del ramo sul `main` ramo.


|  |  | 
| --- |--- |
| Convenzione di denominazione: | `main` | 

## ramo bugfix
<a name="bugfix-branch"></a>

Il `bugfix` ramo è un ramo a breve termine che viene utilizzato per risolvere problemi nei rami di rilascio che non sono stati rilasciati in produzione. Una `bugfix` filiale deve essere utilizzata solo per promuovere le correzioni nelle `release` filiali negli ambienti di test, staging o produzione. Una `bugfix` filiale è sempre ramificata da una filiale. `release`

Dopo che il bugfix è stato testato, può essere promosso al `release` ramo tramite una richiesta di unione. Quindi puoi far avanzare il `release` ramo seguendo la procedura di rilascio standard.


|  |  | 
| --- |--- |
| Convenzione di denominazione: | `bugfix/<ticket>_<developer initials>_<descriptor>` | 
| Esempio di convenzione di denominazione: | `bugfix/123456_MS_Fix_Problem_A` | 

## ramo hotfix
<a name="hotfix-branch"></a>

La `hotfix` filiale è una filiale a breve termine utilizzata per risolvere problemi di produzione. Viene utilizzato solo per promuovere correzioni che devono essere accelerate per raggiungere l'ambiente di produzione. Un `hotfix` ramo è sempre ramificato da. `main`

Dopo aver testato l'hotfix, è possibile promuoverlo alla produzione tramite una richiesta di unione nel `release` ramo da cui è stato creato. `main` Per il test, è quindi possibile portare avanti il `release` ramo seguendo la procedura di rilascio standard.


|  |  | 
| --- |--- |
| Convenzione di denominazione: | `hotfix/<ticket>_<developer initials>_<descriptor>` | 
| Esempio di convenzione di denominazione: | `hotfix/123456_MS_Fix_Problem_A` |