Il problema con il primo approccio è che le funzionalità devono passare attraverso il ramo develop dello sviluppatore prima che raggiungano il repository condiviso. Ciò significa che se uno sviluppatore ha pubblicato una richiesta di pull per una funzionalità importante e importante che richiede parecchie discussioni, revisioni, approvazioni e modifiche, si aggrapperà al loro ramo develop e non saranno in grado di inviare richieste pull più piccole in attesa di altre azioni / decisioni relative a quel grande PR.
In sostanza, il ramo locale develop diventa un collo di bottiglia di blocco per ogni sviluppatore.
Il problema con il secondo approccio è che le funzionalità sono testate dopo sono fuse nel ramo develop del repository condiviso. Ciò significa che puoi inserire del codice errato che rovinerà il progetto per tutti finché non verrà risolto. Inoltre, se decidi di posticipare o abbandonare una funzionalità perché è troppo difficile da correggere o perché non puoi risolverla senza rovinare la progettazione generale, devi modificare la cronologia del ramo di sviluppo del repository condiviso, il che non è una cosa molto divertente da fare ...
In sostanza, il ramo condiviso (!) develop diventa un collo di bottiglia di blocco per l'intero team (!!) .
Quindi - Suggerisco un terzo approccio, che evita questi problemi:
- Crea un nuovo ramo per funzionalità.
- Funzionalità di implementazione.
- Filiale funzionalità di prova.
- Crea richiesta di pull sul ramo di sviluppo.
- Unisci richiesta pull.
- Conferma che tutto funzioni.
- Unisci sviluppo in master.
In questo modo, il tubo di blocco è il ramo della funzione - e dal momento che puoi averne quanti ne vuoi, non è un collo di bottiglia.