La clonazione del repository sul computer locale dello sviluppatore è già una sorta di biforcazione. Se ogni sviluppatore utilizza il repository su GitHub, questo serve solo a pubblicare il loro stato attuale di lavoro.
Questo può essere appropriato quando c'è un repository master centrale e molti contributori che non sono affidabili con accesso diretto a quel repository. Questo funziona perfettamente per progetti open-source in cui tutti possono contribuire e pubblicare una richiesta di pull che viene poi esaminata e unita da un gruppo di manutentori principali. L'utilizzo di più repos applica un flusso di lavoro basato sulla richiesta di pull.
In un team piccolo e fidato, questo non è necessario. Per evitare che persone diverse si comportino reciprocamente, è possibile seguire una strategia come Git Flow: ogni piccola funzionalità è implementata su un ramo di funzione separato. Quando la funzione è completa, viene unita al ramo principale. La maggior parte delle squadre lo accoppierà con una richiesta di pull o una revisione del codice per convenzione, ma sono abbastanza affidabili da saltarlo se necessario. Mentre i repository separati porterebbero a uno sviluppatore che pubblica il loro stato attuale sui loro repository biforcati ma visibili a squadra, in un singolo repository comune invierebbero le loro modifiche a un ramo di funzione separato. Lo svolgimento di tutti gli sviluppi su master / trunk è strongmente sconsigliato nella maggior parte dei flussi di lavoro.
La differenza finisce esclusivamente per la gestione degli accessi e non tanto per il flusso di lavoro implementato. È possibile eseguire flussi di lavoro basati sulla richiesta di pull con entrambe le impostazioni. Da un punto di vista Git non c'è molta differenza tra un fork e un branch - o approcci essenzialmente condividono la cronologia del progetto e consentono di aggiungere commit senza influenzare altri rami / fork. Considerando questo, sarebbe molto meglio condividere un singolo repository quando si è in un gruppo fidato e chiuso.