I workflow visti finora erano accomunati dal fatto di avere comunque un singolo repository remoto di riferimento, che poteva eventualmente usare i branch per isolare gli sviluppi. Nell’approccio “forking” invece, viene creato un repository separato da quello principale, creando, quindi, una nuova e separata struttura di collaborazione.
Questo tipo di approccio è spesso presente nei progetti open source in cui è necessaria una sorta di “protezione” sul repository principale, per cui solo alcuni sviluppatori (maintainer) possono effettivamente accedere a tale repository per creare branch e integrare codice. Altri sviluppatori possono autonomamente creare i propri fork, fare le proprie modifiche e poi, eventualmente, proporle per l’inclusione nel repository originale.
La gestione effettiva del rapporto tra repository originale (upstream) e repository fork è fatta tramite i “remote” di Git, sulla cui base servizi come GitHub e GitLab hanno, effettivamente, implementato le rispettive funzionalità di fork e gli strumenti per aprire richieste di merge verso il repository upstream.
Vantaggi:
- semplifica gestione dei permessi su team grandi o comunque con collaboratori “spot”
- posso creare, condividere e mantenere un mio fork (personale o aziendale) con modifiche che magari non è necessario integrare upstream
Svantaggi:
richiede buona conoscenza dell’uso di remote multipli
