Implementare il flusso di lavoro con fork

Completato

Un fork è una copia di un repository. La creazione di fork di un repository consente di sperimentare liberamente le modifiche senza influire sul progetto originale.

In genere, i fork vengono usati per proporre modifiche al progetto di un altro utente o usare il progetto di qualcun altro come punto di partenza per l'idea.

Un fork è una copia completa di un repository, inclusi tutti i file, i commit e (facoltativamente) i rami.

I fork sono un ottimo modo per supportare un flusso di lavoro di origine interna: è possibile creare un fork per suggerire modifiche quando non si dispone dell'autorizzazione per scrivere direttamente nel progetto originale. Quando si è pronti a condividere tali modifiche, è facile contribuire con le pull request.

Cosa c'è in una forchetta?

Un fork inizia con tutto il contenuto del relativo repository upstream (originale). È possibile includere tutti i rami o limitarli solo al ramo predefinito quando si crea un fork.

Note importanti:

• Nessuna delle autorizzazioni, dei criteri o delle pipeline di compilazione viene copiata.
• Il nuovo fork opera come se qualcuno avesse clonato il repository originale e ne avesse eseguito il push in un nuovo repository vuoto.
• Dopo aver creato un fork, i nuovi file, le cartelle e i rami non vengono condivisi tra i repository, a meno che una richiesta pull non li contenga.

Condivisione del codice tra i fork

È possibile creare pull request in entrambe le direzioni: da fork a upstream o da upstream a fork. L'approccio 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.

Scelta tra rami e fork

• Small Teams (2-5 developers): è consigliabile lavorare in un unico repository. Tutti devono lavorare in un ramo a tema e il ramo principale deve essere protetto con i criteri ramo.

• Team più grandi: quando il team cresce, è possibile che questa organizzazione non sia più sufficiente e che sia preferibile passare a un flusso di lavoro di fork.

• Quando usare i fork:

  • Il repository ha molti collaboratori casuali o poco frequenti ,ad esempio un progetto open source.
  • Solo i collaboratori principali hanno diritti di commit diretto nel repository.
  • Si vuole che i collaboratori esterni al team di base lavorino da un fork.
  • Si vogliono isolare le modifiche fino a quando non si ha la possibilità di esaminare il lavoro.

Flusso di lavoro di fork

Di seguito sono indicati i passaggi base per il flusso di lavoro di fork:

1. Creare un fork.
2. Clonalo a livello locale.
3. Apportare le modifiche in locale e eseguirne il push in un ramo.
4. Creare e completare una richiesta pull upstream.
5. Sincronizzare il fork con la versione più recente upstream.

Passaggio 1: Creazione del fork

1. Passare al repository di cui creare il fork e scegliere "Fork".
2. Specificare un nome e scegliere il progetto in cui si vuole creare il fork.
3. Se il repository contiene molti rami di argomento, è consigliabile creare una copia tramite fork solo del ramo predefinito.
4. Scegliere i puntini di sospensione, quindi "Fork" per creare il fork.

Annotazioni

Per creare un fork, è necessario disporre dell'autorizzazione Crea repository nel progetto scelto. È consigliabile creare un progetto dedicato per i fork in cui tutti i collaboratori dispongono dell'autorizzazione Crea repository.

Passaggio 2: Clona il fork localmente

Quando il fork è pronto, clonarlo usando la riga di comando o un IDE come Visual Studio. Il fork sarà l'origine remota.

git clone {your_fork_url}
For convenience, after cloning, you'll want to add the upstream repository (where you forked from) as a remote named upstream:

```bash
git remote add upstream {upstream_url}

Passaggio 3: Apportare le modifiche e effettuare il push

È possibile lavorare direttamente nel ramo principale: dopo tutto, il fork è la copia del repository. Tuttavia, è consigliabile continuare a lavorare in un ramo dell'argomento perché:

• Consente di gestire più flussi di lavoro indipendenti contemporaneamente.
• Riduce successivamente la confusione quando desideri sincronizzare le modifiche nel tuo fork.

Effettua e committa le modifiche come faresti normalmente. Una volta apportate le modifiche, eseguirne il push nell'origine (il fork).

Passaggio 4: Creare e completare una pull request

Aprire una richiesta pull dal fork al repository upstream. Tutti i criteri, le revisioni richieste e le compilazioni verranno applicati nel repository upstream. Una volta soddisfatti tutti i criteri, la richiesta pull può essere completata e le modifiche diventano parte permanente del repository upstream.

Importante

Chiunque disponga dell'autorizzazione di lettura può aprire una richiesta pull upstream. Se è configurata una pipeline di compilazione di richieste pull, la compilazione verrà eseguita sul codice introdotto nel fork.

Passaggio 5: Sincronizzare il fork con la versione più recente

Quando la richiesta pull viene accettata in upstream, è necessario assicurarsi che il fork rifletta lo stato più recente del repository.

È consigliabile riassegnare le modifiche al ramo principale upstream (presupponendo che principale sia il ramo di sviluppo principale):

git fetch upstream main
git rebase upstream/main
git push origin

Vantaggi del flusso di lavoro fork

Il flusso di lavoro basato su fork consente di isolare le modifiche dal repository principale fino a quando non si è pronti a integrarle. Quando si è pronti, l'integrazione del codice è semplice quanto il completamento di una richiesta pull.

Questo approccio offre:

• Sicurezza: le modifiche vengono isolate fino a quando non vengono esaminate.
• Collaborazione: più persone possono lavorare contemporaneamente su diverse funzionalità.
• Qualità: tutte le modifiche passano attraverso lo stesso processo di revisione.
• Flessibilità: i collaboratori non necessitano dell'accesso in scrittura al repository principale.