Immagina il seguente repository git:
/
/ProductA/product_a_main.py
/ProductB/product_b_main.py
/SharedLibrary/shared_library.py
SharedLibrary è utilizzato da ProductA e ProductB . ProductA e ProductB hanno programmi di rilascio diversi. Qualche consiglio su come gestire la ramificazione in questo scenario? Immagino che un modello dovrebbe avere due rami principali: master_a e master_b .
Mantenere i tre progetti in repository separati aiuterà la gestione del rilascio (come hai notato), ma sarà piacevole per lo sviluppo. Uno sviluppatore che lavora sulla libreria condivisa non ha bisogno di sapere nulla su ProductA o ProductB, che contribuirà a mantenerlo a un buon livello di astrazione (specialmente se si finisce per creare un ProjectC). Gli sviluppatori che lavorano ai progetti principali non hanno bisogno di conoscere l'altro progetto, e saranno incoraggiati ad evitare modifiche alla libreria condivisa come un trucco rapido per ottenere qualcosa lavorando. Ho visto alcuni progetti API davvero scadenti quando viene aggiunto un nuovo metodo ogni volta che uno sviluppatore client vuole una modifica. Gli sviluppatori di progetti possono anche tenere più facilmente aggiornata la libreria senza estrarre le modifiche dal progetto, o mantenere la libreria su una vecchia versione durante il debug delle modifiche.
Se hai un buon ambiente di test e usi l'integrazione continua, tenere separati i repository renderà anche più facile eseguire i test. Quando si apporta una modifica a ProjectA, non si desidera eseguire tutti i test da ProjectB e SharedLibrary.
Il più grande potenziale problema che riesco a vedere è il codice che si interrompe quando le versioni del progetto e della libreria non corrispondono. Ciò sarebbe evitato conservandoli in un repository (quindi le modifiche ad entrambi possono essere fatte nello stesso commit). Se i progetti e la libreria stanno cambiando rapidamente insieme, potrebbe valerne la pena tenerli in un unico pronti contro termine.
Come hai detto, Google e Facebook utilizzano questa strategia poiché hanno molti sviluppatori che lavorano su progetti e librerie. Tuttavia, investono anche in molti potenti server di build e test e hanno bisogno di modifiche per propagarsi il più rapidamente possibile. Se uno sviluppatore migliora l'efficienza di MapReduce, i costi dell'attesa di ogni altro team per ottenere quel cambiamento sono piuttosto grandi.
Se vuoi mantenere tutto sincronizzato in ogni momento, e stai bene con la gestione dei tempi di compilazione / test, allora un repository è tutto ciò di cui hai bisogno. Se le modifiche alla libreria non interromperanno in genere il codice del progetto, le modifiche ai progetti di solito non richiedono modifiche al codice della libreria e si desidera mantenere le cose semplici, quindi cercare repository separati. È più facile unire i repository che dividerli, quindi come regola raccomanderei di iniziare con repository separati finché non si incontrano problemi.
Una cosa da notare è che il sistema di sottomodelli di git può essere problematico. Non ho mai lavorato con questo, ma questo tipo ha alcune lamentele. Questo tizio ha qualche consiglio su come decidere se usare o meno i sottomoduli git che sono un po 'più equilibrati, ma comunque prudenti.
Idealmente, questo sarebbe suddiviso in tre repository, ognuno dei quali potrebbe avere le proprie filiali e il proprio processo di rilascio. Potresti anche mantenere un repository "principale" con riferimenti del sottomodulo agli altri tre, se lo volevi davvero.
Altrimenti, penso che potresti voler avere 3 rami master (per ProdottoA, ProdottoB e per SharedLib), uno per ogni repository e creare versioni da essi. Potresti anche voler sviluppare un ramo fuori da ciascuno di questi maestri e quindi mostrare i rami che escono dai rami di sviluppo. Sarebbe molto più ordinato e pulito con repository separati - è veramente bisogno di fare in questo modo?