Utilizzo di più repository Git invece di uno singolo contenente molte app di team diversi? [duplicare]

Hai a che fare con più team e più progetti. Probabilmente decenni di lavoro sono entrati nel codebase.

La risposta breve è che i team e i progetti hanno esigenze e dipendenze variabili diverse.

L'approccio di repository monolitico riduce i commit a "Tutto è stabile in questa configurazione !!!" (cioè irrealistici, enormi commit provenienti da molte squadre). Questo, o molti punti intermedi di incompatibilità per molti progetti. In ogni caso, c'è un sacco di energia sprecata investita nel supportare configurazioni che semplicemente non avrebbero mai dovuto essere.

I repository dovrebbero invece essere strutturati in modo indipendente e dovrebbero avere più repository che rappresentano le loro dipendenze. Le dipendenze devono essere configurate, aggiornate e testate dai manutentori del progetto nei punti appropriati dello sviluppo.

• ProjectA ha visto la sua ultima major release 3 anni fa. È in modalità di manutenzione e ha requisiti di sistema "più vecchi". Dovrebbe fare riferimento a un insieme appropriato di dipendenze. Ha 20 dipendenze.
• ProjectB è stato appena rilasciato. Ha requisiti di sistema più moderni ed è stato sviluppato e testato da un altro team. Dispone di 15 librerie dipendenti (= repos), 10 delle quali sono condivise con ProjectA. Questi progetti generalmente si riferiscono a diversi commit delle loro librerie dipendenti. Le dipendenze vengono aggiornate nei punti appropriati dello sviluppo.
• ProjectC deve ancora essere rilasciato. È molto simile a ProjectB, ma include cambiamenti significativi e miglioramenti alle sue dipendenze. Gli sviluppatori di ProjectB sono interessati solo a prendere le versioni stabili delle dipendenze che condividono con ProjectC. Il team di ProjectB si impegna a rispettare le dipendenze condivise, anche se al momento sono principalmente correzioni di bug e ottimizzazioni. Un repository monolitico potrebbe contenere lo sviluppo di ProjectC per mantenere il supporto per ProjectA, o le modifiche di ProjectC potrebbero interrompere A e B, oppure gli sviluppatori finirebbero per non condividere / riutilizzare il codice.

Con più repository (distribuiti), ciascun team può lavorare in modo indipendente e minimizzare l'impatto sugli altri progetti, riutilizzando e migliorando costantemente le codebase. Ciò impedisce anche alle squadre di spostare focus / velocità quando i cambiamenti arrivano da altri team. Il repository monolitico centralizzato rende ogni squadra dipendente dalla mossa di ogni squadra e dovrebbe essere sincronizzata.

Non sembra esserci un argomento a favore del grande repository in questo thread, quindi eccone uno:

Il vantaggio di un grande repo con tutto il tuo codice è che hai una fonte affidabile di verità. Tutto lo stato del tuo progetto globale è rappresentato nella storia di quel repository. Non ti devi preoccupare di domande come "Quale versione di libA ho bisogno di costruire libB da 3 mesi fa?" o "I test di integrazione hanno avuto esito negativo a causa del cambiamento di Susan in libC o del cambiamento di Bob in libD?" o "Sono rimasti dei chiamanti per evilMethod ()?" È tutto nella storia.

Quando i progetti correlati sono suddivisi in repository separati, git non tiene traccia delle loro relazioni per te. Il tuo sistema di compilazione deve sapere dove trovare il codice per tutte le sue dipendenze e, soprattutto, quale versione del codice da compilare. Puoi "costruire tutto solo dal master", ma questo rende difficile riprodurre le build passate, difficile apportare modifiche (o rollback) che devono essere sincronizzate tra i repository e difficile mantenere le filiali in uno stato stabile.

Quindi la domanda non è "Un grande repository o molti piccoli repository?" In realtà è "Un grande repository o molti piccoli repository con strumenti ." Che strumento hai intenzione di usare? Repo (Android) e gclient (Chromium) di Google sono due esempi. I sottomoduli Git sono un altro. Tutti hanno major downsides che devi pesare contro i lati negativi di un grande repo.

Modifica: qui ci sono alcune altre risposte Scegliere tra progetti singoli o multipli in un repository git?

PS: tutto ciò che ho detto, sto lavorando a uno strumento per migliorare le cose, quando devo dividere i repository o usare il codice di altre persone: link

Git tende a riscontrare problemi di prestazioni quando viene utilizzato con repository di grandi dimensioni.

Per quote di Linus :

And git obviously doesn't have that kind of model at all. Git
fundamnetally never really looks at less than the whole repo. Even if you limit things a bit (ie check out just a portion, or have the history go back just a bit), git ends up still always caring about the whole thing, and carrying the knowledge around.

So git scales really badly if you force it to look at everything as one huge repository. I don't think that part is really fixable, although we can probably improve on it.

Enfasi mia. Questo non vuol dire che il repository di controllo della versione della tua azienda sia "grande", ma questo è uno dei motivi per cui le persone tendono ad evitare grandi repository all'interno di Git.

They want [something that can] show their changes across all projects instead of trying to remember what project they made a change [to].

Sourcetree (un frontend Git della GUI free-as-in-beer) ti consente di registrare più repository, organizzali in gruppi logici, quindi visualizza lo stato su tutti contemporaneamente:

Non sono affiliato con loro in alcun modo.

TL; DR; l'equivalente di un repository git è un modulo CVS, non un repository CVS.

CVS è progettato con l'idea che i moduli siano una suddivisione di un repository ed è comune usare repository CVS con diversi moduli che hanno una vita abbastanza indipendente. Ad esempio, è facile avere rami specifici per un modulo e non presenti in un altro.

git non è stato progettato con una nozione di modulo, ogni repository git è limitato a un modulo in termini di CVS. Quando crei un ramo, è valido per l'intero repository.

Quindi, se vuoi importare un repository CVS con diversi moduli in git, è meglio creare un repository per modulo, specialmente se i moduli hanno una vita più o meno indipendente e non condividono cose come branch ed etichette. (A causa dei diversi modelli di utilizzo delle filiali in CVS e git, si può anche valutare l'utilità di disporre di un repository per ramo CVS, ma per una migrazione da CVS a git, è probabile che il flusso di lavoro all'inizio sia abbastanza simile a un flusso di lavoro CVS che non vale il dolore).

Se sei disposto a giocare con loro per placare, puoi configurarlo in questo modo . Oppure questo metodo . Oltre a questo, penso che si aspettino solo un singolo punto di accesso al sistema per accedere alle risorse.

A seconda delle esigenze di accesso, i repository GIT separati potrebbero ancora essere la soluzione migliore, poiché "John Smith" potrebbe avere bisogno di accedere a determinati dati, ma non ad altri dati. Mentre "Suzy Que" potrebbe essere un amministratore di sistema che ha bisogno di accedere a tutto.

Se utilizzi un unico repository, potresti riscontrare problemi con i tuoi requisiti di accesso interno. Se si tratta di un tipo di "tutti ottiene pieno accesso", allora potrei vedere il loro punto di vista.

Git migration help page di Eclipse suggerisce di riorganizzare l'albero delle directory CVS / SVN in più repository Git:

Now is a great time to refactor your code structure. Map the current CVS/SVN directories, modules, plugins, etc. to their new home in Git. Typically, one Git repository (.git) is created for each logical grouping of code -- a project, a component, and so on.

Gli argomenti:

The trade-off here is that each additional Git repository adds extra overhead to your development process - all Git commands and operations happen at the level of a single Git repository. On the flip side, each repository user will have an entire copy of the repository history, making very large repositories cumbersome to work with for casual contributors.

Git funziona su un intero albero contemporaneamente, non solo sulla sottodirectory in cui ti trovi.

Supponiamo di avere il tuo progetto in

C:\MyCode\ProjectABC

Diciamo che questi due file sono cambiati:

C:\MyCode\ProjectABC\stuff.txt
C:\MyCode\ProjectABC\Stuff\MoreStuff\morestuff.txt

Quando sei nella root del progetto e fai lo stato git, vedrai che questi file sono cambiati:

stuff.txt
Stuff\MoreStuff\morestuff.txt

Se cd nella directory MoreStuff, vedrai solo il file morestuff.txt? No. Vedrai comunque entrambi i file, relativi alla tua posizione:

..\..\stuff.txt
morestuff.txt

Di conseguenza, se riunisci tutti i tuoi progetti in un unico grande repository Git, ogni volta che vai al check-in, dovrai scegliere tra i cambiamenti in ogni progetto .

Ora potrebbero esserci modi per mitigarlo; ad esempio, puoi provare a verificare almeno temporaneamente le modifiche prima di passare a un altro progetto. Ma questo è un sovraccarico che ogni persona del tuo team dovrebbe affrontare, rispetto a farlo semplicemente nel modo giusto: un repository Git per progetto.