Forks

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

Visual Studio 2019 | Visual Studio 2022

I fork del repository Git sono utili quando gli utenti vogliono apportare modifiche sperimentali, rischiose o nascoste a una codebase, ma queste modifiche devono essere isolate dalla codebase nel repository originale. Un nuovo fork è fondamentalmente un nuovo repository remoto che condivide il codice sorgente del repository originale.

Come versione indipendente, le modifiche apportate al fork, ad esempio l'aggiunta di commit o rami, sono nascoste al repository originale. Se si desidera unire le modifiche della codebase nel repository originale, è necessario creare una richiesta pull per richiedere la revisione e l'approvazione di tali modifiche.

Il processo di fork non trasferisce autorizzazioni, criteri o pipeline di compilazione dal repository originale al fork.

Questo articolo illustra l'uso dei fork nei repository Git di Azure Repos e fornisce collegamenti a contenuto GitHub che illustra come gestire i fork nei repository GitHub.

In questo articolo viene spiegato come:

Prerequisiti per l'accesso a Azure Repos

Condividere il codice tra fork

Il repository originale viene spesso definito repository upstream . È possibile creare richieste pull per unire le modifiche in entrambe le direzioni: da fork a upstream o upstream a fork. La direzione più comune è da fork a upstream. Le autorizzazioni, i criteri, le compilazioni e gli elementi di lavoro del repository di destinazione verranno applicati alla richiesta pull.

Scegliere tra rami e fork

Per un piccolo team di sviluppatori da 2 a 5, un flusso di lavoro di fork potrebbe non essere necessario perché tutti possono lavorare nei rami delle funzionalità e nei criteri dei rami possono proteggere il ramo predefinito. Tuttavia, se il team espande e espande questa disposizione, può passare a un flusso di lavoro di fork.

Se il repository ha un numero elevato di commit casuali o poco frequenti, ad esempio un progetto open source, è consigliabile usare il flusso di lavoro di creazione di fork. In genere, solo i collaboratori principali del progetto devono avere diritti di commit diretti per il repository originale. Altri collaboratori devono usare un flusso di lavoro di fork per isolare le modifiche proposte fino a quando i collaboratori principali non hanno la possibilità di esaminare il proprio lavoro.

Abilitare i fork del repository

Per abilitare i fork per un repository Git di Azure Repos, vedere Abilitare i fork.

Per abilitare i fork per un repository GitHub, vedere Gestione dei criteri di fork per l'organizzazione.

Flusso di lavoro di fork

Il flusso di lavoro di fork è costituito da cinque passaggi descritti nelle sezioni seguenti.

1. Creare un fork
2. Clonare il fork in locale
3. Eseguire il push delle modifiche locali nel fork
4. Creare e completare una richiesta pull
5. Sincronizzare il fork

Creare un fork

I passaggi seguenti descrivono come creare una copia tramite fork di un repository Git di Azure Repos.

1. Dal Web browser passare al repository Git Azure Repos che si vuole creare tramite fork. Selezionare File di repository > e quindi scegliere Fork dal menu con i puntini di sospensione per aprire la finestra di dialogo Fork.

   

2. Nella finestra di dialogo Fork denominare il repository con fork, scegliere il progetto in cui si vuole creare il fork, selezionare i rami da includere nel fork e quindi scegliere Fork. È possibile specificare se il fork conterrà tutti i rami o solo il ramo predefinito. Se il repository contiene diversi rami di argomento, prendere in considerazione solo l'inclusione del ramo predefinito nel fork.

   

Per informazioni su come creare una copia tramite fork di un repository GitHub, vedere Creare una copia tramite fork di un repository.

Clonare il fork in locale

Dopo aver creato una copia tramite fork di un repository, clonare il fork per creare una copia locale in una cartella nel computer. È possibile clonare dalla riga di comando o usando un IDE come Visual Studio. Per altre informazioni sulla clonazione di un repository, vedere Clonare un repository Git esistente.

Quando si clona un repository remoto, Git assegna l'alias origin come abbreviato per l'URL del repository remoto clonato. Per praticità, aggiungere un altro alias denominato upstream per il repository da cui è stato eseguito il fork, denominato repository upstream. I passaggi seguenti descrivono come aggiungere un upstream alias.

git remote add upstream <clone URL>

git remote set-url upstream <clone URL>

Eseguire il push delle modifiche locali nel fork

Quando si crea una copia tramite fork, si crea una versione personale del repository originale (il repository originale viene definito "upstream"). Il fork è indipendente dall'upstream, ma il fork condivide il codice e mantiene un collegamento all'upstream, consentendo una sincronizzazione futura. Quindi, non c'è nulla che impedisca di lavorare direttamente nel main ramo del clone locale e quindi di eseguire il push del lavoro nel main ramo del fork. Tuttavia, in genere è preferibile usare rami di funzionalità per il lavoro. Usando i rami di funzionalità:

• È possibile gestire più flussi di lavoro indipendenti contemporaneamente.

• È più semplice per gli altri comprendere il lavoro condiviso perché tale lavoro è organizzato in flussi di lavoro distinti per ramo.

Un flusso di lavoro Git tipico include questi passaggi:

1. Creare una funzionalità locale o un ramo di correzione di bug.

2. Apportare modifiche nel nuovo ramo ed eseguire il commit del lavoro. In genere, le persone effettuano più commit quando si lavora su una funzionalità o una correzione di bug.

3. Eseguire il push della funzionalità o del ramo di correzione di bug nel fork. Il fork ha l'alias origin.

Per informazioni su come eseguire il push delle modifiche, vedere Condividere il codice con il push.

Creare e completare una richiesta pull

In Azure Repos, per eseguire il merge nel repository originale le modifiche di cui è stato eseguito il push nel fork, è possibile:

1. Creare una richiesta pull per richiedere la revisione e l'approvazione delle modifiche. Quando si apre una richiesta pull, impostare il ramo di origine della richiesta pull sulla funzionalità o sul ramo di correzione di bug nel fork. Il ramo di destinazione della richiesta pull è in genere il main ramo del repository creato tramite fork. Tale repository viene definito repository upstream e ha l'alias upstream.

   Lo screenshot seguente mostra il repository di origine e il ramo e il repository di destinazione e il ramo di una richiesta pull creata in Azure Repos.

   

   Per altre informazioni su come creare una richiesta pull usando il browser, Visual Studio o l'interfaccia della riga di comando di Azure DevOps, vedere Creare una richiesta pull.

   Importante

   Chiunque disponga dell'autorizzazione di lettura per il repository upstream può aprire una richiesta pull. Se il repository upstream ha una pipeline di compilazione pull configurata per l'esecuzione nella creazione della richiesta pull, verrà eseguita una compilazione sulle modifiche introdotte dalla richiesta pull.

2. Per il completamento della richiesta pull, tutti i revisori necessari devono approvare le modifiche della richiesta pull e tutti i criteri dei rami di destinazione devono essere soddisfatti. Al termine dell'approvazione e del completamento della richiesta pull, le modifiche nel ramo di origine della richiesta pull verranno unite nel ramo di destinazione della richiesta pull.

Per informazioni su come creare e completare una richiesta pull di GitHub, vedere Creazione di una richiesta pull e Unione di una richiesta pull.

Sincronizzare il fork

Dopo che una richiesta pull unisce le modifiche dal fork nel ramo di destinazione del repository upstream, è possibile eseguire il pull dal ramo di destinazione del repository upstream per aggiornare il ramo locale corrispondente con le modifiche apportate da altri collaboratori. Quindi si è pronti per:

• Creare una nuova funzionalità o un ramo di correzione di bug dal ramo locale aggiornato.

• Aggiornare il fork eseguendo il push dal ramo locale aggiornato a origin.

In genere, il ramo di destinazione del repository upstream è main. Se non si modifica direttamente il ramo locale main (si lavora in rami di funzionalità), il pull dal ramo upstream/main upstream aggiornerà il ramo locale main senza conflitti di merge.

Passaggi successivi

Articoli correlati

• Novità dei repository Git? Altre informazioni
• Aggiornare il codice con recupero, unione e pull
• Salvare il lavoro con i commit