Il precedente progetto in cui ho lavorato raggruppava molti linguaggi e servizi nello stesso repository e forniva una scatola di Vagrant che dava a questo un ambiente di sviluppo completo.
Ciò significava che tutte le pagine esterne, le API del client, i microservizi interni e così via erano accessibili fin dall'inizio. Ci sono voluti solo due comandi per fare in modo che un nuovo sviluppatore diventasse un insieme di servizi utilizzabili per iniziare a programmare. Come sottolinea Doc Brown nel suo commento, è molto importante la relazione del codice. Tutti i servizi in questa configurazione erano strettamente interconnessi e inutilizzabili l'uno con l'altro. Non è detto che non ci fossero altri motivi per dividere il codice base.
A volte i repository sono decisamente separati. I più grandi motivi per cui riesco a vedere la parte superiore della mia testa;
- Se vuoi limitare strettamente l'accesso - Forse alcuni utenti non dovrebbero poter accedere ad alcune applicazioni / lingue / codice
- Diverse persone lavorano sulle diverse basi di codice e non hanno relazioni tra loro
- La dimensione di una singola lingua / codice base / applicazione è abbastanza grande da giustificarlo
- Inizi a creare e utilizzare repository di pacchetti interni / esterni - Credo fermamente che dovresti avere un repository per pacchetto / modulo che distribuisci con repository
Detto questo, per la maggior parte dei progetti di sviluppo interni in cui tutti possono o dovrebbero essere in grado di accedere a tutto il codice e non sono necessari processi di implementazione di fantasia, un approccio più rozzo va bene. Nel mio attuale progetto abbiamo diviso il codice front-end e il codice back-end in due repository separati poiché ci sono gruppi distinti che lavorano sui loro lati separati.
Penso che il miglior consiglio che posso dare sia:
Use one repository until you have a reason to divide the code base into multiple repositories, then ask yourself again if you really have a reason to divide it.
Nel tuo caso sembra esserci una ragione per dividere i repository ma se nessuno dei punti sopra elencati è soddisfatto o ti rende incapace di dormire la notte, ti consiglio caldamente di dividere il codice in questo momento.