Forks

  • Articolo

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

Visual Studio 2019 | Visual Studio 2022

I fork git sono utili quando gli utenti vogliono apportare modifiche sperimentali, rischiose o riservate a una codebase, ma queste modifiche devono essere isolate dalla codebase nel repository originale. Un nuovo fork è fondamentalmente un clone del repository originale sottoposto a push in un nuovo repository remoto. Il fork è indipendente dal repository originale ed è una copia completa a meno che non si specifichi un singolo ramo.

Come copia indipendente, le modifiche apportate al fork, ad esempio l'aggiunta di commit o rami, non vengono condivise con il 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:

  • Condividere il codice tra fork
  • Scegliere tra rami e fork
  • Abilitare i fork del repository
  • Creare un fork
  • Clonare il fork in locale
  • Eseguire il push delle modifiche locali nel fork
  • Creare e completare una richiesta pull
  • Sincronizzare il fork

Prerequisiti per l'accesso a Azure Repos

  • I repository devono essere abilitati nelle impostazioni del progetto Azure DevOps. Se l'hub Repos e le pagine associate non vengono visualizzate, vedere Attivare o disattivare un servizio Azure DevOps per riabilitare Repos.

  • Per visualizzare il codice nei progetti privati, è necessario essere membri di un progetto Azure DevOps con livello di accesso Basic o superiore. Per i progetti pubblici, tutti possono visualizzare il codice.

  • Per clonare o contribuire al codice per un progetto privato, è necessario essere membri del gruppo di sicurezza Collaboratori o disporre del set di autorizzazioni corrispondente. Per i progetti pubblici, chiunque può clonare e contribuire al codice. Per altre informazioni, vedere Che cos'è un progetto pubblico?

    Nota

    Per i progetti pubblici, gli utenti a cui è concesso l'accesso degli stakeholder hanno accesso completo ad Azure Repos.

  • I repository devono essere abilitati nelle impostazioni del progetto Azure DevOps. Se l'hub Repos e le pagine associate non vengono visualizzate, vedere Attivare o disattivare un servizio Azure DevOps per riabilitare Repos.

  • Per visualizzare il codice, è necessario essere membri del progetto Azure DevOps con accesso Basic o versione successiva. Se non si è membri del progetto, viene aggiunto.

  • Per clonare o contribuire al codice, è necessario essere membri del gruppo di sicurezza Collaboratori o disporre delle autorizzazioni corrispondenti nel progetto da modificare.

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.

Nota

Per creare una copia tramite fork di un repository in un progetto Azure DevOps, è necessario disporre dell'autorizzazione Crea repository per tale progetto. I proprietari del repository devono prendere in considerazione la creazione di un progetto dedicato per i fork e l'assegnazione dell'autorizzazione Crea repository a tutti i collaboratori. Per altre informazioni sull'impostazione delle autorizzazioni, vedere Impostare le autorizzazioni del repository Git.

  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.

    Screenshot della voce di menu Fork nel menu Altre azioni nella pagina File di repository in Azure Repos.

  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.

    Screenshot della finestra di dialogo Fork nella pagina File di repository in Azure Repos.

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.

Suggerimento

Per praticità, è possibile usare gli origin alias e upstream anziché gli URL corrispondenti nei comandi Git.

Per aggiungere un upstream alias in Visual Studio, seguire questa procedura:

  1. Scegliere Opzioni strumenti > dalla barra dei menu per aprire la finestra Opzioni. Selezionare Repository Git controllo del codice > sorgente Impostazioni > Remote e quindi scegliere Aggiungi per aprire la finestra di dialogo Aggiungi remoto.

    Screenshot del pulsante Aggiungi nel riquadro Remotes (Remote) del sottomenu Git Repository Impostazioni del menu Controllo del codice sorgente in Visual Studio 2019.

  2. Nella finestra di dialogo Aggiungi remoto aggiungere un nuovo remoto denominato upstream e immettere l'URL clone Git del repository copiato tramite fork. Scegliere quindi Salva.

    Screenshot della finestra di dialogo Aggiungi remoto in Visual Studio 2019.

Eseguire il push delle modifiche locali nel fork

Quando si crea una copia tramite fork, si crea una copia personale e indipendente del repository remoto. 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.

    Screenshot delle opzioni origine e ramo di destinazione della richiesta pull 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

Condividere il codice con le richieste pull di revisione push