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

Sottoprogetti è il luogo in cui sono stati distribuiti i sistemi di controllo della versione (DVCS), se non svelati, sicuramente diventerà un po 'traballante.

Git sottomoduli e Mercurial subrepository mirano entrambi al supporto del sottoprogetto. Entrambi hanno migliorato la release per versione (al punto che la vecchia "caratteristica di Mercurial esiste, ma probabilmente non dovresti usarla", l'avvertimento non è più frontale e centrale).

Tuttavia, i repository multi-progetto rimangono più un caso di utilizzo di specialità piuttosto che una funzione di tutti gli usi. La documentazione contiene numerosi avvertimenti e istruzioni su come utilizzare questo, che chiariscono che gestire i "progetti di progetti" è una preoccupazione a due livelli, con la gestione dei metadati leggermente diversa ma genuinamente diversa dalla gestione diretta del progetto a livello singolo. Di conseguenza, c'è molta meno esperienza là fuori. E non c'è carenza di "non usare git submodules!" e "evita i subrepos mercuriali!" commenti e post sul blog.

La mia esperienza con i subrepos è stata mista. Ha funzionato ... ma era anche noioso. Adoro l'idea di sottoprogetti, ma in pratica trovo le alternative - o grandi repository all-in-one o progetti fratelli gemelli - per essere più facilmente contrastanti (anche se meno eleganti). Non vedo l'ora che i subrepos del giorno siano mainstream e non un dolore, ma non l'ho ancora provato.

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

Dato che sei concentrato su Git, dovresti anche esplorare i sottoalberi Git, che alcuni trovano essere una migliore alternativa ai sottomodelli git .

Se usi C #, puoi utilizzare NuGet.

Rendi ciascun componente una libreria e conservali nel proprio repository. Crea versioni dei componenti di base della tua versione in base alla versione semantica.

Infine, fai in modo che buildserver impacchetta le librerie in pacchetti NuGet e consumi quei pacchetti NuGet nei progetti per i componenti front-end (iOS, Android).

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

Non ti consiglierei di usare Git Submodule. Anche se in teoria può essere usato per questi tipi di problemi, ritengo che sia una seccatura maggiore di quanto valga.

Secondo me, ciò dipenderebbe da quanto effettivamente sono accoppiati. È davvero bello essere in grado di eseguire un git bisect automatico quando si effettua il tracciamento di una regressione, ma sarà difficile farlo se ogni commit dipende da una versione diversa delle altre dipendenze da eseguire.

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

how would you be able to "link" these repositories so that you would know that version 2.0 of the app requires version 1.5 of the server component, etc?

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