Christopher ha svolto un ottimo lavoro nell'enumerazione degli svantaggi di un modello di un progetto per singolo repository. Vorrei discutere alcuni dei motivi per cui potresti considerare un approccio a repository multipli. In molti ambienti in cui ho lavorato, un approccio multi-repository è stato una soluzione ragionevole, ma la decisione di quanti repository avere e dove fare i tagli non è sempre stata facile.
Nella mia attuale posizione, ho migrato un repository CVS di un singolo repository di Behemoth con oltre dieci anni di storia in una serie di repository git. Da quella decisione iniziale, il numero di repository è cresciuto (attraverso le azioni di altri team), al punto in cui sospetto che avremmo più di quanto sarebbe ottimale. Alcuni neoassunti hanno suggerito di unire i repository ma ho discusso contro di esso. Il progetto Wayland ha un'esperienza simile. In un discorso che ho visto di recente, avevano, a un certo punto, oltre 200 repository git, per i quali il lead si scusava. Guardando il loro sito web , vedo ora che sono a 5, il che sembra ragionevole. È importante osservare che unire e suddividere i repository è un compito gestibile, ed è giusto sperimentare (entro limiti ragionevoli).
Quindi quando potresti volere più repository?
- Un singolo repository sarebbe troppo grande per essere efficiente.
- I repository sono liberamente accoppiati o disaccoppiati.
- Generalmente uno sviluppatore ha bisogno solo di uno o di un piccolo sottoinsieme di repository da sviluppare.
- In genere vuoi sviluppare i repository in modo indipendente e devi solo sincronizzarli occasionalmente.
- Vuoi incoraggiare più modularità.
- Diversi team lavorano su diversi repository.
I punti 2 e 3 sono significativi solo se il punto 1 vale. Suddividendo i nostri repository, ho ridotto in modo significativo i ritardi subiti dai colleghi esterni, ridotto il consumo di dischi e migliorato il traffico di rete.
4 e 5 sono più sottili. Quando dividi i repository di un client e un server, ciò rende più costoso coordinare le modifiche tra il codice client e il codice server. Questo può essere positivo, in quanto incoraggia un'interfaccia disaccoppiata tra i due.
Anche con gli aspetti negativi dei progetti multi-repository, un sacco di lavoro rispettabile viene svolto in questo modo: vengono in mente wayland e boost. Non credo che un consenso sulle migliori pratiche si sia evoluto ancora, e sia necessario un certo giudizio. Gli strumenti per lavorare con più repository (git-subtree, git-submodule e altri) sono ancora in fase di sviluppo e sperimentazione. Il mio consiglio è di sperimentare ed essere pragmatico.