Usando múltiplos repositórios Git ao invés de um único contendo muitos aplicativos de diferentes equipes? [duplicado]

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.

Não parece haver um argumento a favor do grande repo neste tópico, então aqui está uma:

A vantagem de um grande repo com todo o seu código é que você tem uma fonte confiável de verdade. Todo o estado em seu projeto abrangente é representado na história do repo. Você não precisa se preocupar com perguntas como "Qual versão do libA eu preciso para construir o libB de 3 meses atrás?" ou "Os testes de integração começaram a falhar devido à mudança de Susan na libC ou à mudança de Bob na libD?" ou "Há algum visitante deixado para o evilMethod ()?" Está tudo na história.

Quando projetos relacionados são divididos em repos separados, o git não está acompanhando seus relacionamentos para você. Seu sistema de compilação precisa saber onde encontrar o código para todas as suas dependências e, mais importante, qual versão do código a ser construído. Você pode "apenas construir tudo a partir do mestre", mas isso dificulta a reprodução de compilações anteriores, é difícil fazer alterações (ou reversões) que precisem ser sincronizadas em repos e manter as ramificações em um estado estável.

Então a pergunta não é "Um grande repo ou muitos pequenos repos?" Na verdade, é "um grande repo ou muitos pequenos repos com ferramentas ." Qual ferramenta você vai usar? Repo (Android) e gclient (Chromium) do Google são dois exemplos. Submodules Git é outro. Todos eles têm principais downsides que você precisa ponderar em relação às desvantagens de um grande repo.

Editar: aqui estão mais algumas respostas Escolhendo entre projetos únicos ou múltiplos em um repositório git?

PS: Tudo o que disse, estou trabalhando em uma ferramenta para tornar as coisas melhores, para quando você tiver que dividir repos ou usar o código de outras pessoas: link

O Git tende a ter problemas de desempenho quando usado em grandes repositórios.

Para citar 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.

Ênfase minha. Isso não quer dizer que o repositório de controle de versão da sua empresa seja "grande", mas essa é uma das razões pelas quais as pessoas tendem a evitar grandes repositórios dentro do 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 (um front-end GUI Git gratuito como cerveja) permite registrar vários repositórios, organize-os em grupos lógicos e, em seguida, visualize o status em todos eles de uma só vez:

Eu não sou afiliado a eles de nenhuma maneira.

TL; DR; o equivalente a um repositório git é um módulo CVS, não um repositório CVS.

O CVS é projetado com uma noção de módulos sendo uma subdivisão de um repositório, e é comum usar repositórios CVS com vários módulos que possuem uma vida bastante independente. Por exemplo, é fácil ter ramificações específicas para um módulo e não estar presente em outro.

git não foi projetado com uma noção de módulo, cada repositório git é limitado a um módulo no termo CVS. Quando você cria uma ramificação, ela é válida para todo o repositório.

Assim, se você quiser importar um repositório CVS com vários módulos no git, é melhor criar um repositório por módulo, especialmente se os módulos tiverem uma vida mais ou menos independente e não compartilharem coisas como branch e labels. (Devido a diferentes padrões de uso de ramificações no CVS e git, você pode até investigar a utilidade de ter um repositório por ramificação de CVS; mas para uma migração do CVS para git, é provável que seu fluxo de trabalho seja similar o suficiente um fluxo de trabalho CVS que não vale a pena).

Se estiver disposto a jogar bola com eles para apaziguar, poderá configurá-lo desta forma . Ou este método . Além disso, acho que eles estão apenas esperando um único ponto de entrada no sistema para acessar ativos.

Dependendo das necessidades de acesso, os repositórios separados do GIT ainda podem ser a melhor opção, já que "John Smith" pode precisar de acesso a determinados dados, mas não a outros dados. Enquanto "Suzy Que" pode ser um sistema de administração que precisa de acesso a tudo.

Se você optar por um único repo, poderá encontrar problemas com seus requisitos de acesso interno. Se é um tipo de "todo mundo tem acesso total", então eu poderia ver o ponto de vista deles.

A página de ajuda da migração do Git do Eclipse sugere reorganizar a árvore de diretórios CVS / SVN em vários repositórios 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.

Os argumentos:

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.

O Git opera em uma árvore inteira de uma só vez, não apenas no subdiretório em que você está.

Digamos que você tenha seu projeto em

C:\MyCode\ProjectABC

E digamos que esses dois arquivos foram alterados:

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

Quando você está no projeto root e faz um status git, verá esses arquivos como alterados:

stuff.txt
Stuff\MoreStuff\morestuff.txt

Se você cd para o diretório MoreStuff, no entanto, verá apenas o arquivo morestuff.txt? Não. Você ainda verá os dois arquivos, relativos à sua posição:

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

Como resultado, se você juntar todos os seus projetos em um grande repositório Git, toda vez que for fazer o check-in, terá que escolher entre as alterações em cada projeto .

Agora, pode haver maneiras de atenuar isso; Por exemplo, você pode tentar certificar-se de que, pelo menos temporariamente, faça as alterações antes de passar a trabalhar em um projeto diferente. Mas isso é muita sobrecarga que cada pessoa em sua equipe teria que lidar, em comparação com simplesmente fazê-lo da maneira certa: um repositório Git por projeto.