Flusso di lavoro di fork

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.

È 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.

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.

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.

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:

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.

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:

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

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:

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:

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

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:

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.

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.