Forchette
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 permessi, policy o pipeline di build dal repository originale al tuo 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 biforcazioni
- Abilitare i fork del repository
- Creare un fork
- Clonare il fork localmente
- Effettuare il push delle modifiche locali sul fork
- Creare e completare una richiesta pull
- Sincronizza il tuo fork
Prerequisiti
| Categoria | Requisiti |
|---|---|
| Accesso al progetto | Membro di un progetto. |
| Autorizzazioni | - Visualizzare il codice nei progetti privati: almeno accesso Basic. - Clonare o contribuire al codice nei progetti privati: membro del gruppo di sicurezza dei Contributori o con autorizzazioni corrispondenti nel progetto. - Impostare i permessi per il ramo o il repository: Gestire le autorizzazioni autorizzazioni per il ramo o il repository. - Modificare il ramo predefinito: Modificare i criteri autorizzazioni per il repository. - Importare un repository: membro del gruppo di sicurezza , amministratori del progetto, o del gruppo di sicurezza Git a livello di progetto , Crea repository impostato su Consenti. Per altre informazioni, vedere Impostare le autorizzazioni del repository Git. |
| Servizi | Repos abilitato. |
| Strumenti | Opzionale. Usare i comandi az repos: l'interfaccia della riga di comando di Azure DevOps. |
Nota
Nei progetti pubblici, gli utenti con l'accesso degli stakeholder hanno accesso completo ad Azure Repos, inclusa la visualizzazione, la clonazione e il contributo al codice.
| Categoria | Requisiti |
|---|---|
| Accesso al progetto | Membro di un progetto. |
| Autorizzazioni | - Visualizza codice: almeno accesso Basic . - Clonare o contribuire al codice: membro del gruppo di sicurezza dei collaboratori o delle relative autorizzazioni nel progetto. |
| Servizi | Repos abilitato. |
Condividere il codice tra i fork
Il repository originale viene spesso chiamato upstream. È possibile creare richieste pull per unire le modifiche in entrambe le direzioni: dal fork all'upstream o dall'upstream al 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 al pull request.
Scegliere tra rami e biforcazioni
Per un piccolo team di sviluppatori da 2 a 5 persone, un workflow di forking potrebbe non essere necessario perché tutti possono lavorare nei rami delle funzionalità e le politiche dei rami possono proteggere il ramo predefinito. Tuttavia, se il tuo team si espande e supera questa configurazione, può passare a una metodologia a 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 dovrebbero usare un flusso di lavoro di fork per isolare le modifiche proposte fino a quando i contributori principali non hanno avuto la possibilità di revisionare il loro 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.
- Creare un fork
- Clona il tuo fork localmente
- Eseguire il push delle modifiche locali sul tuo fork
- Creare e completare una pull request
- Sincronizza il tuo fork
Creare una diramazione
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 avere l'autorizzazione Create 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.
Dal tuo browser web, naviga al repository Git di Azure Repos che vuoi fare un fork. Selezionare File di repository > e quindi scegliere Fork dal menu con i puntini di sospensione per aprire la finestra di dialogo Fork.
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.
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:
Scegliere > strumenti dalla barra dei menu per aprire la finestra Opzioni. Selezionare Controllo del codice sorgente > Impostazioni > repository Git Remotes, e quindi scegliere Aggiungi per aprire la finestra Aggiungi remoto.
Nella finestra di dialogo Aggiungi remoto aggiungere un nuovo remoto denominato
upstreame immettere l'URL clone Git del repository copiato tramite fork. Scegliere quindi Salva.
Fai il push delle modifiche locali sul fork
Quando fai un fork, crei 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, nulla ti impedisce di lavorare direttamente nel main ramo del clone locale e successivamente di eseguire il push del lavoro nel main ramo del tuo fork. Tuttavia, in genere è preferibile usare branch di funzionalità per il tuo lavoro. Usando i rami funzionali:
È 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:
Creare una funzionalità locale o un ramo di correzione di bug.
Apporta modifiche nel nuovo ramo ed esegui il commit del lavoro. In genere, le persone effettuano più commit quando si lavora su una funzionalità o una correzione di bug.
Eseguire il push della funzionalità o del ramo di correzione di bug nel fork. Il tuo 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 pull request
In Azure Repos, per eseguire il merge nel repository originale delle modifiche di cui è stato eseguito il push nel fork, puoi:
Crea una pull request per chiedere la revisione e l'approvazione delle tue 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
mainramo del repository creato tramite fork. Tale repository viene definito repository upstream e ha l'aliasupstream.Lo screenshot seguente mostra il repository e il ramo di origine e il repository e il ramo di destinazione 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 in Project Valid Users e con l'autorizzazione Read per il repository upstream può aprire una pull request. Se il repository upstream ha una pipeline di costruzione delle richieste pull configurata per l'esecuzione alla creazione di una richiesta pull, verrà eseguita una compilazione sulle modifiche introdotte dalla tua richiesta pull.
Per completare il pull request, tutti i revisori necessari devono approvare le modifiche al pull request e devono essere soddisfatti tutti i criteri del branch di destinazione. 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 su GitHub, vedere Creazione di una richiesta pull e Unione di una richiesta pull.
Sincronizza il fork
Dopo che una richiesta pull unisce le modifiche dal tuo fork nel ramo di destinazione del repository upstream, puoi eseguire il pull dal ramo di destinazione del repository upstream per aggiornare il tuo ramo locale corrispondente con le tue modifiche e quelle apportate da altri collaboratori. Quindi si è pronti per:
Creare una nuova funzionalità o un ramo di correzione di bug dal ramo locale aggiornato.
Aggiorna il tuo fork eseguendo il push dal tuo 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.