Test pubblicazione 12/16
Usare un ramo per isolare il lavoro di sviluppo senza influire sugli altri rami del repository. Ogni repository ha un ramo predefinito e può avere più altri rami. È possibile unire un ramo in un altro ramo usando una richiesta di pull.
In questo articolo |
|
---|---|
Informazioni sui rami
I rami consentono di sviluppare funzionalità, correggere bug o sperimentare in modo sicuro nuove idee in un'area contenuta del repository.
Si crea sempre un ramo da un ramo esistente. In genere, è possibile creare un nuovo ramo dal ramo predefinito del repository. È quindi possibile lavorare su questo nuovo ramo in isolamento dalle modifiche apportate da altri utenti al repository. Un ramo creato per creare una funzionalità viene comunemente definito ramo caratteristica o ramo argomento. Per altre informazioni, vedere "Creazione ed eliminazione di rami all'interno del repository".
È anche possibile usare un ramo per pubblicare un sito pagine GitHub. Per ulteriori informazioni, vedi "Informazioni sulle pagine GitHub".
È necessario avere accesso in scrittura a un repository per creare un ramo, aprire una richiesta di pull o eliminare e ripristinare rami in una richiesta pull. Per ulteriori informazioni, vedi "Autorizzazioni di accesso su GitHub".
Informazioni sul ramo predefinito
Quando crei un repository con contenuto su GitHub, GitHub crea il repository con un unico ramo. Questo primo ramo nel repository è il ramo predefinito. Il ramo predefinito è il ramo visualizzato da GitHub quando chiunque visita il repository. Il ramo predefinito è anche il ramo iniziale che Git estrae localmente quando qualcuno clona il repository. A meno che non si specifichi un ramo diverso, il ramo predefinito in un repository è il ramo di base per le nuove richieste pull e i commit del codice.
Per impostazione predefinita, GitHub assegna un nome alla branch main predefinita in qualsiasi nuovo repository.
È possibile modificare il ramo predefinito per un repository esistente. Per altre informazioni, vedere "Modifica del ramo predefinito".
È possibile impostare il nome del ramo predefinito per i nuovi repository. Per altre informazioni, vedere "Gestione del ramo predefinito per i repository", "Gestione del nome di ramo predefinito per i repository nell'organizzazione" e "Applicazione dei criteri di gestione dei repository nell'account aziendale".
Uso dei rami
Una volta soddisfatti del lavoro, è possibile aprire una richiesta di pull per unire le modifiche nel ramo corrente (il ramo head) in un altro ramo (il ramo base). Per altre informazioni, vedere "Informazioni sulle richieste di pull."
Dopo aver unito o chiuso una richiesta di pull, è possibile eliminare il ramo head in quanto non è più necessario. Per eliminare i rami, è necessario disporre dell'accesso in scrittura nel repository. Non è possibile eliminare i rami direttamente associati alle richieste di pull aperte. Per ulteriori informazioni, vedi "Eliminazione e ripristino di rami in una richiesta di pull"
Se elimini un ramo head dopo che la sua richiesta di pull è stata unita, GitHub verifica la presenza di eventuali richieste di pull aperto nello stesso repository che specificano il ramo eliminato come ramo di base. GitHub aggiorna automaticamente tali richieste di pull, modificando il ramo base del ramo di base della richiesta pull unita. I diagrammi seguenti illustrano questo aspetto.
Qui qualcuno ha creato un ramo chiamato feature1 dal ramo principale ed è stato quindi creato un ramo denominato feature2 da feature1. Sono presenti richieste di pull aperte per entrambi i rami. Le frecce indicano il ramo di base corrente per ogni richiesta di pull. A questo punto, feature1 è il ramo di base per feature2. Se la richiesta di pull per la caratteristica2 è ora unita, il ramo feature2 verrà unito nella caratteristica1.
Nel diagramma successivo un utente ha unito la richiesta di pull per feature1 nel ramo master e ha eliminato il ramo feature1. Di conseguenza, GitHub ha ridestinato automaticamente la richiesta di pull per la funzionalità2 in modo che il suo ramo base sia ora master.
A questo punto, quando si unisce la richiesta di pull feature2, questa viene unita al ramo principale.
Utilizzo di rami protetti
Gli amministratori del repository possono abilitare le protezioni in un ramo. Se si lavora su un ramo protetto, non sarà possibile eliminare o forzare il push al ramo. Gli amministratori di repository possono inoltre abilitare diverse altre impostazioni di ramo protetto per applicare vari flussi di lavoro prima che un ramo possa essere unito.
Nota: Se sei un amministratore del repository, puoi unire le richieste pull nei rami con le protezioni dei rami abilitate anche se la richiesta pull non soddisfa i requisiti, a meno che le protezioni di ramo non siano state impostate su "Includi amministratori".
Per verificare se la richiesta di pull può essere unita, esaminare la casella di unione nella parte inferiore della schedaConversation della richiesta di pull. Per altre informazioni, vedere "Informazioni sui rami protetti".
Quando un ramo è protetto:
-
Non sarà possibile eliminare o forzare il push al ramo.
-
Se i controlli di stato obbligatori sono abilitati nel ramo, non sarà possibile unire le modifiche nel ramo finché non vengono superati tutti i test CI necessari. Per altre informazioni, vedere "Informazioni sui controlli di stato".
-
Se le revisioni richieste di pull sono abilitate nel ramo, non sarà possibile unire le modifiche nel ramo fino a quando non sono stati soddisfatti tutti i requisiti nei criteri di revisione della richiesta di pull. Per altre informazioni, vedere "Unione di una richiesta di pull".
-
Se la revisione obbligatoria da parte di un proprietario del codice è abilitata in un ramo e una richiesta di pull modifica il codice che ha un proprietario, il proprietario del codice deve approvare la richiesta di pull prima che possa essere unita. Per altre informazioni, vedere "Informazioni sui proprietari del codice".
-
Se è abilitata la firma di commit obbligatoria in un ramo, non sarà possibile eseguire il push dei commit nel ramo che non sono firmati e verificati. Per altre informazioni, vedere "Informazioni sul commit della verifica della firma" e "Informazioni sui rami protetti".
-
Se si usa l'editor dei conflitti di GitHub per correggere i conflitti per una richiesta di pull creata da un ramo protetto, GitHub consente di creare un ramo alternativo per la richiesta di pull, in modo che la risoluzione dei conflitti possa essere unita. Per altre informazioni, vedere "Risoluzione di un conflitto di unione in GitHub".
Ulteriori letture
"Informazioni sulle richieste di pull"
"Branch" nel glossario di GitHub
"Rami in poche parole" nella documentazione Git