Você está lidando com várias equipes e vários projetos. Prováveis décadas de trabalho foram para a base de código.
A resposta curta é que suas equipes e projetos têm necessidades variadas e dependências variadas.
A abordagem do repositório monolítico reduz os commits para "Tudo é estável nesta configuração !!!" (isto é, compromissos irreais e enormes obtidos de muitas equipes). Isso, ou muitos pontos intermediários de incompatibilidades para muitos projetos. De qualquer maneira, há muita energia desperdiçada investida em configurações de suporte que simplesmente nunca foram feitas para ser.
Seus repositórios devem ser estruturados de forma independente, e devem ter vários repositórios que representam suas dependências. As dependências devem ser configuradas, atualizadas e testadas pelos mantenedores do projeto em pontos apropriados no desenvolvimento.
- O ProjectA viu seu último grande lançamento há três anos. Está no modo de manutenção e possui requisitos de sistema "antigos". Deve referir-se a um conjunto apropriado de dependências. Tem 20 dependências.
- O ProjectB acabou de ser lançado. Tem requisitos de sistema mais modernos e foi desenvolvido e testado por outra equipe. Tem 15 bibliotecas dependentes (= repos), 10 das quais são compartilhadas com o ProjectA. Esses projetos geralmente se referem a diferentes commits de suas bibliotecas dependentes. Dependências são atualizadas em pontos apropriados no desenvolvimento.
- O ProjectC ainda está para ser lançado. É muito semelhante ao ProjectB, mas inclui mudanças significativas e melhorias em suas dependências. Os desenvolvedores do ProjectB só estão interessados em obter as versões estáveis das dependências que compartilham com o ProjectC. A equipe do ProjectB faz alguns commits para as dependências compartilhadas, embora sejam principalmente correções de bugs e otimizações no momento. Um repositório monolítico manteria o desenvolvimento do ProjectC de volta para manter o suporte para o ProjectA, ou as mudanças do ProjectC quebrariam A e B, ou os desenvolvedores acabariam não compartilhando / reutilizando código.
Com vários repositórios (distribuídos), cada equipe pode trabalhar de forma independente e minimizar o impacto nos outros projetos enquanto reutiliza e aprimora constantemente as bases de código. Isso também impede que as equipes mudem de foco / velocidade quando as mudanças chegam de outras equipes. O repositório monolítico centralizado faz com que cada equipe dependa do movimento de cada equipe, e isso teria que ser sincronizado.