I collaboratori su un repository Github privato dovrebbero fork ogni repo?

Al momento sto lavorando a un progetto e abbiamo il codice sorgente in un repository privato su Github, con ognuno di noi come collaboratore.

Ciò su cui non siamo chiari è come separare ciascuno dei nostri lavori.

Quello che penso che dobbiamo fare è:

1. Ognuno di noi ha bisogno di fork del repository
2. Quando siamo pronti a inviare il nostro codice, inviamo quindi una richiesta pull al repository del leader del progetto, che può allo stesso tempo utilizzarlo come un'opportunità per fare una revisione del codice

Quando si tratta di repository privati, è per questo che dovrebbe essere usato il fork o sto complicando eccessivamente la situazione?

La clonazione del repository sulla macchina locale dello sviluppatore è già una sorta di fork. Se ogni sviluppatore esegue il fork del repository su GitHub, ciò serve solo a pubblicare il loro attuale stato di lavoro.

Ciò può essere appropriato in presenza di un repository principale centrale e di molti collaboratori che non si fidano dell'accesso diretto a tale repository. Questo funziona alla grande per progetti open source in cui tutti possono contribuire ed emettere una richiesta pull che viene quindi rivista e unita da un gruppo di manutentori principali. L'uso di più repository impone un flusso di lavoro basato su richieste pull.

In un piccolo team fidato, questo non è necessario. Per evitare che persone diverse si intralcino, è possibile seguire una strategia come Git Flow: ogni piccola funzionalità è implementata su un ramo di funzionalità separato. Quando la funzione è completa, viene unita nel ramo principale. La maggior parte dei team abbinerà questo con una richiesta pull o una revisione del codice per convenzione, ma sono abbastanza fidati da saltare questo, se appropriato. Mentre repository separati porterebbero uno sviluppatore a pubblicare il proprio stato corrente sui repository biforcati ma visibili in team, in un singolo repository comune spingerebbero le loro modifiche in un ramo di funzionalità separato. Fare tutto lo sviluppo su master / trunk è altamente scoraggiato nella maggior parte dei flussi di lavoro.

La differenza sta solo nella gestione degli accessi e non tanto nel flusso di lavoro implementato. È possibile eseguire flussi di lavoro basati su richieste pull con entrambe le impostazioni. Dal punto di vista di Git, non c'è molta differenza tra un fork e un ramo: entrambi gli approcci condividono essenzialmente la storia del progetto e consentono di aggiungere commit senza influire su altri rami / fork. Considerando questo, sarebbe molto meglio condividere un singolo repository quando in un gruppo fidato e chiuso.

Questo funzionerebbe, oppure potresti usare un metodo di ramificazione in cui ogni contrib ha i suoi rami, che quando il team è d'accordo, si fondono con il master.