Flusso di lavoro di fork

Il flusso di lavoro di forking è fondamentalmente diverso dagli altri flussi di lavoro Git più noti. Invece di utilizzare un singolo repository lato server come codebase "centrale", tramite il fork ogni sviluppatore avrà a disposizione un proprio repository lato server. Di conseguenza, ogni collaboratore non avrà uno, ma due repository Git: uno privato locale e uno pubblico lato server. Il flusso di lavoro di forking è presente più spesso nei progetti open source pubblici.

Il vantaggio principale del flusso di lavoro di forking è che i contributi possono essere integrati senza che tutti debbano eseguire il push in un unico repository centrale. Gli sviluppatori eseguono il push nei propri repository lato server, mentre il push nel repository ufficiali può essere effettuato solo dal responsabile del progetto, che può quindi accettare commit da tutti gli sviluppatori senza concedere loro l'accesso in scrittura al codebase ufficiale.

Il flusso di lavoro di forking in genere segue un modello di ramificazione basato sul flusso di lavoro Gitflow. Ciò significa che per il merge nel repository originale del responsabile del progetto verranno utilizzati feature branch completi. Ne risulta un flusso di lavoro distribuito che offre estrema flessibilità e sicurezza durante la collaborazione tra team organici di grandi dimensioni (comprese terze parti non affidabili). Questo lo rende anche un flusso di lavoro ideale per progetti open source.  

Come funziona

Come negli altri flussi di lavoro Git, il flusso di lavoro di forking inizia con un repository pubblico ufficiale archiviato su un server. Tuttavia, quando un nuovo sviluppatore vuole iniziare a lavorare sul progetto, non clona direttamente il repository ufficiale.

Al contrario, esegue un fork del repository ufficiale per crearne una copia sul server. Questa nuova copia funge da repository pubblico personale: nessun altro sviluppatore è autorizzato a eseguirvi il push, ma può eseguire il pull delle modifiche (tra poco vedremo perché è importante). Dopo aver creato la propria copia lato server, lo sviluppatore esegue un clone Git per scaricarne una copia sul proprio computer locale. Questo funge da ambiente di sviluppo privato, proprio come negli altri flussi di lavoro.

Quando è pronto a pubblicare un commit locale, ne esegue il push al proprio repository pubblico, non a quello ufficiale. Quindi, presenta una pull request al repository principale, che consente al responsabile del progetto di sapere che un aggiornamento è pronto per essere integrato. La pull request funge anche da comodo thread di discussione in caso di problemi con il codice fornito. Quello che segue è un esempio dettagliato di questo flusso di lavoro.

1. Uno sviluppatore "esegue un fork" di un repository "ufficiale" lato server. Questo gli permette di creare una copia propria lato server.

2. La nuova copia lato server viene clonata nel suo sistema locale.

3. Un percorso remoto Git per il repository "ufficiale" viene aggiunto al clone locale.

4. Viene creato un nuovo feature branch locale.

5. Lo sviluppatore apporta modifiche al nuovo branch.

6. Vengono creati nuovi commit per le modifiche.

7. Il branch viene trasferito alla copia lato server dello sviluppatore.

8. Lo sviluppatore apre una pull request dal nuovo branch al repository "ufficiale".

9. La pull request viene approvata per il merge e viene unita al repository originale lato server

Per integrare la funzione nel codebase ufficiale, il responsabile estrae le modifiche del collaboratore nel proprio repository locale, verifica che non compromettano il progetto, le unisce nel branch principale locale, quindi esegue il push del branch principale al repository ufficiale sul server. Il contributo fa ora parte del progetto e gli altri sviluppatori eseguiranno il pull dal repository ufficiale per sincronizzare i propri repository locali.

È importante capire che il concetto di repository "ufficiale" nel flusso di lavoro di forking non è altro che una convenzione. In effetti, l'unico aspetto che rende tale il repository ufficiale è dato dal fatto che questo è il repository pubblico del responsabile del progetto.

Forking e clonazione a confronto

È importante notare che i repository "derivati" e il "forking" non sono operazioni speciali. I repository derivati vengono creati utilizzando il comando git clone standard. I repository derivati sono generalmente cloni "lato server" e solitamente sono gestiti e ospitati in un servizio Git di terze parti come Bitbucket. Non esiste un comando Git univoco per creare repository derivati. Un'operazione di clonazione consiste essenzialmente nella copia di un repository e della sua cronologia. 

Branching nel flusso di lavoro di forking

Tutti questi repository personali rappresentano in realtà solo un modo conveniente per condividere branch con altri sviluppatori. Tutti dovrebbero continuare a utilizzare i branch per isolare le singole funzionalità, proprio come nel flusso di lavoro di feature branching e nel flusso di lavoro Gitflow. L'unica differenza risiede nella condivisione dei branch. Nel flusso di lavoro di forking, i branch vengono inseriti nel repository locale di un altro sviluppatore, mentre nel feature branching e nei flussi di lavoro Gitflow vengono inviati al repository ufficiale.

Eseguire un fork di un repository

Tutti i nuovi sviluppatori di un progetto nel flusso di lavoro di forking devono eseguire un fork del repository ufficiale. Come affermato in precedenza, il forking è solo un'operazione di clonazione Git standard. È possibile farlo inserendo un SSH nel server ed eseguendo il comando git clone per copiarlo in un'altra posizione sul server. I servizi di hosting Git più diffusi, come Bitbucket, offrono funzionalità di forking dei repository che automatizzano questo passaggio.

Clonare un fork

Tutti i nuovi sviluppatori di un progetto nel flusso di lavoro di forking devono eseguire un fork del repository ufficiale. Come affermato in precedenza, il forking è solo un'operazione di clonazione Git standard. È possibile farlo inserendo un SSH nel server ed eseguendo il comando git clone per copiarlo in un'altra posizione sul server. I servizi di hosting Git più diffusi, come Bitbucket, offrono funzionalità di forking dei repository che automatizzano questo passaggio.

Supponendo l'uso di Bitbucket per ospitare questi repository, gli sviluppatori di un progetto dovrebbero avere il proprio account Bitbucket e clonare la loro copia derivata del repository nei modi seguenti:

1git clone https://user@bitbucket.org/user/repo.git

Aggiungendo un remote

Mentre altri flussi di lavoro Git utilizzano un unico remote di origine che punta al repository centrale, il flusso di lavoro di forking richiede due remoti, uno per il repository ufficiale e uno per il repository personale lato server dello sviluppatore. Sebbene questi remoti possano essere denominati come si desidera, una convenzione comune consiste nell'usare "origine" come remote per il repository derivato (questo verrà creato automaticamente quando si esegue git clone) e "upstream" per il repository ufficiale.

1git remote add upstream https://bitbucket.org/maintainer/repo

Dovrai creare tu stesso il remote upstream usando il comando precedente. Questo ti permetterà di mantenere facilmente aggiornato il tuo repository locale man mano che il progetto ufficiale avanza. Ricorda che, se nel tuo repository upstream è abilitata l'autenticazione (ossia, non è open source), dovrai fornire un nome utente, come ad esempio:

1git remote add upstream https://user@bitbucket.org/maintainer/repo.git

Ciò richiede che gli utenti forniscano una password valida prima della clonazione o dell'estrazione dal codebase ufficiale.

Lavorare in un branch: apportare modifiche ed eseguirne il push

Nella copia locale del repository derivato dello sviluppatore, quest'ultimo può eseguire il commit delle modifiche, apportare modifiche e creare branch, proprio come in altri flussi di lavoro Git:

1git checkout -b some-feature # Edit some code git commit -a -m "Add first draft of some feature"

Tutte le modifiche saranno totalmente private finché lo sviluppatore non ne esegue il push nel proprio repository pubblico. Inoltre, se il progetto ufficiale è andato avanti, lo sviluppatore potrà accedere a nuovi commit con git pull:

1git pull upstream main

Poiché gli sviluppatori dovrebbero lavorare in un feature branch dedicato, ciò dovrebbe in genere comportare un merge rapido.

Come effettuare una pull request

Una volta che uno sviluppatore è pronto a condividere la sua nuova funzione, deve fare due cose. Innanzitutto, dovrà rendere il proprio contributo accessibile ad altri sviluppatori eseguendone il push nel repository pubblico. Il remote di origine dovrebbe essere già configurato, quindi non dovrà fare altro che usare il comando seguente:

1git push origin feature-branch

Questo differisce dagli altri flussi di lavoro in quanto il telecomando di origine punta al repository personale lato server dello sviluppatore, non al codebase principale.

In secondo luogo, dovrà notificare al responsabile del progetto di voler unire la propria funzione nel codebase ufficiale. Bitbucket fornisce un "pull request" che porta a un modulo che chiede di specificare quale branch si desidera unire nel repository ufficiale. In genere, il branch di funzioni è integrato nel branch principale del remote upstream.

Riepilogo

Ricapitolando, il flusso di lavoro di forking è comunemente usato in progetti open source pubblici. Il forking è un'operazione di clonazione git eseguita su una copia server di un repository di progetto. Il flusso di lavoro di forking viene spesso utilizzato insieme a un servizio di hosting Git come Bitbucket. Ecco un esempio di alto livello di flusso di lavoro di forking:

1. Desideri contribuire a una libreria open source ospitata su bitbucket.org/userA/open-project

2. Usando Bitbucket, crei un fork del repository su bitbucket.org/TuoNome/open-project

3. Sul tuo sistema locale esegui git clone su https://bitbucket.org/YourName/open-project per ottenere una copia locale del repository

4. Crei un nuovo branch di funzioni nel tuo repository locale

5. Il lavoro per completare la nuova funzione è terminato; il comando git commit ti permette di salvare le modifiche

6. Esegui il push del nuovo branch di funzioni al tuo repository derivato remoto

7. Tramite Bitbucket, apri una pull request per il nuovo branch sul repository originale all'indirizzo bitbucket.org/userA/open-project

Il flusso di lavoro di forking aiuta il responsabile di un progetto ad aprire il repository ai contributi di qualsiasi sviluppatore senza dover gestire manualmente le impostazioni di autorizzazione per ogni singolo collaboratore. Questo offre al responsabile un flusso di lavoro più simile a un "pull". Utilizzato più comunemente nei progetti open source, il flusso di lavoro di forking può essere applicato anche ai flussi di lavoro di business privati per dare un controllo più autorevole su ciò che viene sottoposto a merge in un rilascio. Questo può essere utile nei team con Deploy Manager o cicli di rilascio rigorosi.

Non sai quale sia il flusso di lavoro giusto per te? Dai un'occhiata alla nostra pagina completa di confronto tra i flussi di lavoro Git.