Implementare il flusso di lavoro con fork
Un fork è una copia di un repository. La creazione di una copia di repository tramite fork consente di sperimentare liberamente le modifiche senza influire sul progetto originale.
I fork vengono usati più comunemente per proporre modifiche al progetto di qualcun altro oppure per usare il progetto di qualcun altro come punto di partenza per sviluppare un'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 InnerSource: è possibile creare un fork per suggerire modifiche quando non si dispone dell'autorizzazione per scrivere direttamente nel progetto originale.
Quando si è pronti per condividere quelle modifiche, è possibile proporle facilmente tramite richieste pull.
Cosa contiene un fork?
Un fork inizia con tutto il contenuto del relativo repository upstream (originale).
Quando si crea un fork, è possibile includere tutti i rami o soltanto quello predefinito.
Non viene applicata nessuna delle autorizzazioni, dei criteri o delle pipeline di compilazione.
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, cartelle e rami non vengono condivisi tra i repository, a meno che non vengano trasportati da una richiesta pull.
Condivisione del codice tra i fork
È possibile creare richieste pull in entrambe le direzioni: da fork ad upstream o da upstream a fork.
L'approccio più comune sarà da fork ad upstream.
Le autorizzazioni, i criteri, le build e gli elementi di lavoro del repository di destinazione verranno applicati alla richiesta pull.
Scelta tra rami e fork
Nel caso di un team di piccole dimensioni (2-5 sviluppatori), è consigliabile lavorare in un singolo repository.
Tutti devono lavorare in un ramo a tema e il principale deve essere protetto con i criteri ramo.
Quando il team raggiungerà dimensioni più significative, è possibile che questa organizzazione non sia più sufficiente e sia preferibile passare a un flusso di lavoro di fork.
È consigliabile usare il flusso di lavoro di fork se il repository ha molti esecutori di commit casuali o poco frequenti (come nel caso di un progetto open source).
In genere, solo i collaboratori principali del progetto dispongono di diritti di commit diretto nel repository.
Può essere utile chiedere ai collaboratori esterni a questo set principale di persone di lavorare da un fork del repository.
In questo modo, inoltre, è possibile isolare le loro modifiche dalle proprie fino a quando non saranno state vagliate.
Flusso di lavoro di fork
- Creare un fork.
- Clonarlo in locale.
- Apportare le modifiche in locale e eseguirne il push in un ramo.
- Creare e completare una richiesta pull in direzione upstream.
- Sincronizzare il fork con la versione più recente upstream.
Creare il fork
- Passare al repository di cui creare una copia tramite fork e scegliere Fork.
- Specificare un nome e selezionare il progetto in cui si vuole creare il fork. Se il repository contiene molti rami a tema, è consigliabile creare una copia tramite fork solo del ramo predefinito.
- Scegliere i puntini di sospensione, quindi Fork per creare il fork.
Nota
Per creare un fork, è necessaria l'autorizzazione Crea repository. È consigliabile creare un progetto dedicato per i fork in cui tutti i collaboratori dispongono dell'autorizzazione Crea repository. Per un esempio di concessione di questa autorizzazione, vedere Impostare le autorizzazioni per il repository Git.
Clonare il fork in locale
Quando il fork è pronto, clonarlo usando la riga di comando o un IDE, ad esempio Visual Studio. Il fork sarà l'origine remota.
Per praticità, dopo la clonazione è opportuno aggiungere il repository upstream (da cui è stata creata la copia tramite fork) come repository remoto denominato upstream.
git remote add upstream {upstream_url}
Apportare modifiche ed eseguirne il push
È possibile lavorare direttamente nel ramo principale: dopo tutto, il fork è la copia del repository.
È comunque consigliabile lavorare in un ramo a tema.
In questo modo si possono gestire simultaneamente più flussi di lavoro indipendenti
e inoltre si riduce la confusione in un secondo momento, quando si vogliono sincronizzare le modifiche nel fork.
Apportare le modifiche ed eseguirne il commit, come di consueto. Al termine dell'operazione, eseguire il push delle modifiche nell'origine (il fork).
Creare e completare una richiesta pull
Aprire una richiesta pull dal fork all'upstream. Tutti i criteri, le revisioni richieste e le compilazioni verranno applicati nel repository upstream. Quando tutti i criteri risultano soddisfatti, è possibile completare la richiesta pull. Le modifiche diventeranno parte permanente del repository upstream.
Importante
Chiunque abbia l'autorizzazione di lettura può aprire una richiesta pull in direzione upstream. Se è configurata una pipeline di compilazione della richiesta pull, la compilazione verrà eseguita con il codice introdotto nel fork.
Sincronizzare il fork con la versione più recente
Quando la richiesta pull viene accettata upstream, è opportuno verificare che il fork rifletta lo stato più recente del repository.
A tal fine, è consigliabile riassegnare le modifiche al ramo principale dell'upstream (presupponendo che main sia il ramo di sviluppo principale).
git fetch upstream main
git rebase upstream/main
git push origin
Il flusso di lavoro basato su fork consente di isolare le modifiche dal repository principale fino a quando non si è pronti a integrarle. Quando è tutto pronto, per integrare il codice è sufficiente completare una richiesta pull.