Raggruppamento di più repository Git che fanno parte dello stesso progetto complessivo

Diciamo che ho un progetto che ha più componenti: un componente server, un componente app Web, un componente iOS, un componente Android, ecc. Questi componenti sono tutti basi di codice separate, ma sono anche liberamente accoppiati (ad esempio una modifica al server il codice potrebbe richiedere una modifica anche a tutti gli altri componenti)

Qual è il modo più efficiente in Git per organizzare questo progetto? Se metti tutto in un repository, avresti sempre le ultime versioni ma le cose diventano piuttosto disordinate quando inizi a cambiare un componente e non gli altri.

D'altra parte, se trasformi ciascun componente in un repository separato, come saresti in grado di "collegare" questi repository in modo da sapere che la versione 2.0 dell'app richiede la versione 1.5 del componente server, ecc.?

Esiste una funzionalità in git al di fuori di tenere aggiornati i file (o qualche soluzione migliore che non vedo) per gestire in modo più efficace repository correlati?

I sottoprogetti sono il luogo in cui i sistemi di controllo della versione distribuita (DVCS) iniziano, se non si svelano, diventano sicuramente un po 'traballanti.

I sottomoduli Git e i sottorepository Mercurial mirano entrambi al supporto di sottoprogetti. Entrambi hanno migliorato rilascio per rilascio (al punto che il vecchio "questa funzione esiste, ma probabilmente non dovresti usarla", l'avvertimento di Mercurial non è più in primo piano).

Tuttavia, i repository multi-progetto rimangono più un caso d'uso speciale piuttosto che una funzionalità che tutti usano. La documentazione contiene numerose avvertenze e istruzioni su "come utilizzare" che chiariscono che la gestione di "progetti di progetti" è una preoccupazione a due livelli, con la meta gestione leggermente ma sinceramente diversa dalla gestione diretta a livello singolo. Di conseguenza, c'è molta meno esperienza là fuori. E non mancano "non usare i sottomoduli git!" ed "evita i sottostati mercuriali!" commenti e post di blog.

La mia esperienza con i sottosposi è stata mista. Funzionava ... ma era anche fastidioso. Adoro l'idea di sottoprogetti, ma in pratica trovo che le alternative - grandi repository all-in-one o progetti di fratelli gemelli - possano essere più facilmente distrutte (sebbene meno eleganti). Non vedo l'ora che i sottosposi siano mainstream e non un dolore, ma non l'ho ancora sperimentato.

Questo non vuol dire che la gestione dei sottomoduli / sottosposi non funzionerà per te, ma è qualcosa che dovrebbe essere fatto con cura e sicuramente qualche precedente sperimentazione e pianificazione.

Dato che ti concentri su Git, dovresti anche esplorare i sottotitoli Git, che alcuni trovano essere una migliore alternativa ai sottomoduli di Git .

Se usi C #, puoi usare NuGet.

Rendi ogni componente una libreria e conservali nel loro repository. Rilasciare i componenti di base che si versione in base al controllo delle versioni semantico.

Infine, chiedi al tuo buildserver di impacchettare le librerie in pacchetti NuGet e di consumare quei pacchetti NuGet nei progetti per i componenti front-end (iOS, Android).

Lo stesso approccio di base (dipendenze di versione e pacchetto) può essere utilizzato anche in altre lingue, ma potrebbe non essere altrettanto conveniente.

Non consiglierei di usare i sottomoduli Git. Sebbene possa essere usato per questo tipo di problemi in teoria, penso che sia una seccatura più grande di quanto valga la pena.

Secondo me, ciò dipenderebbe da quanto effettivamente sono accoppiati. È davvero bello poter eseguire un automatizzato git bisectquando si rintraccia una regressione, ma questo sarà difficile da fare se ogni commit dipende da una versione diversa delle altre dipendenze da eseguire.

Due possibili opzioni sarebbero un repository con sottomoduli o repository multipli con buone pratiche di versioning in atto.

come saresti in grado di "collegare" questi repository in modo da sapere che la versione 2.0 dell'app richiede la versione 1.5 del componente server, ecc.?

Questo di solito è il dominio di alcuni framework di gestione delle dipendenze (ad esempio Gradle, Maven), non Git stesso.