Escolha entre projetos únicos ou múltiplos em um repositório git?

Existem três grandes desvantagens em relação a one project per repository , como você descreveu acima. Estes são menos verdadeiros se forem verdadeiros projetos distintos, mas dos sons mudam para um frequentemente requerem mudanças para outro, o que pode realmente exagerar estes problemas:

1. É mais difícil descobrir quando os bugs foram introduzidos. Ferramentas como git bisect se tornam muito mais difíceis de usar quando você divide seu repositório em sub-repositórios. É possível, não é tão fácil, o que significa caça a bugs em tempos de crise é muito mais difícil.
2. O acompanhamento de todo o histórico de um recurso é muito mais difícil. Os comandos de passagem de histórico como git log simplesmente não exibem o histórico de forma tão significativa com estruturas de repositório fragmentadas. Você pode obter alguma saída útil com submódulos ou subárvores, ou por meio de outros métodos de script, mas não é o mesmo que digitar tig --grep=<caseID> ou git log --grep=<caseID> e varrendo todos os commits de que você gosta. Seu histórico fica mais difícil de entender, o que torna menos útil quando você realmente precisa.
3. Novos desenvolvedores gastam mais tempo aprendendo a estrutura do Controle de Versão antes de iniciar a codificação. Todo novo trabalho requer procedimentos de picking, mas fracionar um repositório de projeto significa que eles precisam escolher a estrutura do VC além da arquitetura do código . Na minha experiência, isso é particularmente difícil para desenvolvedores iniciantes que vêm de lojas mais tradicionais e centralizadas que usam um único repositório.

No final, é um cálculo de custo de oportunidade. Em um ex-empregador, nossa aplicação principal estava dividida em 35 sub-repositórios diferentes. Além disso, usamos um conjunto complicado de scripts para pesquisar o histórico, garantir que o estado (ou seja, ramos de produção versus desenvolvimento) fosse o mesmo entre eles e implantá-los individualmente ou em massa.

Foi demais; muito para nós pelo menos. A sobrecarga de gerenciamento tornou nossos recursos menos ágeis, tornou as implantações muito mais difíceis, fez com que o ensino de novos desenvolvedores demorasse muito tempo e, no final, mal conseguimos nos lembrar por que fraturamos o repositório em primeiro lugar. Um belo dia de primavera, gastei US $ 10 por uma tarde de tempo de computação de cluster no EC2. Eu combinei os repositórios novamente com algumas dúzias de git filter-branch de chamadas. Nós nunca olhamos para trás.

Christopher fez um ótimo trabalho ao enumerar as desvantagens de um modelo de um projeto por repositório. Eu gostaria de discutir algumas das razões pelas quais você pode considerar uma abordagem de múltiplos repositórios. Em muitos ambientes em que trabalhei, uma abordagem multi-repositório tem sido uma solução razoável, mas a decisão de quantos repositórios ter e onde fazer os cortes nem sempre foi fácil de ser feita.

Na minha posição atual, migrei um gigantesco repositório CVS de repositório único com mais de dez anos de história para vários repositórios git. Desde essa decisão inicial, o número de repositórios cresceu (através das ações de outras equipes), a ponto de eu suspeitar que temos mais do que seria ótimo. Alguns novos contratados sugeriram a fusão dos repositórios, mas eu argumentei contra isso. O projeto Wayland tem uma experiência semelhante. Em uma palestra que eu vi recentemente, eles tiveram, em um ponto, mais de 200 repositórios git, para os quais o líder se desculpou. Olhando para o seu site , vejo agora que eles estão em 5, o que parece razoável. É importante observar que juntar e dividir repositórios é uma tarefa gerenciável, e não há problema em experimentar (dentro da razão).

Então, quando você pode querer vários repositórios?

1. Um único repositório seria grande demais para ser eficiente.
2. Seus repositórios são fracamente acoplados ou desacoplados.
3. Um desenvolvedor normalmente precisa apenas de um ou de um pequeno subconjunto de seus repositórios para desenvolver.
4. Normalmente, você deseja desenvolver os repositórios de forma independente e só precisa sincronizá-los ocasionalmente.
5. Você quer incentivar mais modularidade.
6. Equipes diferentes trabalham em diferentes repositórios.

Os pontos 2 e 3 são significativos apenas se o ponto 1 for válido. Ao dividir nossos repositórios, diminuí significativamente os atrasos sofridos por nossos colegas externos, reduziu o consumo de disco e melhorou o tráfego de rede.

4 e 5 são mais sutis. Quando você divide os repositórios de, digamos, um cliente e um servidor, isso torna mais caro coordenar as alterações entre o código do cliente e do servidor. Isso pode ser positivo, pois incentiva uma interface desacoplada entre os dois.

Mesmo com as desvantagens dos projetos de multi-repositórios, muito trabalho respeitável é feito dessa maneira - wayland e boost vêm à mente. Eu não acredito que um consenso sobre as melhores práticas tenha evoluído ainda, e algum julgamento é necessário. Ferramentas para trabalhar com múltiplos repositórios (git-subtree, git-submodule e outros) ainda estão sendo desenvolvidas e experimentadas. Meu conselho é experimentar e ser pragmático.

Como usamos o GitHub, na verdade temos vários projetos em um repositório, mas asseguramos que esses projetos / módulos são adequadamente modulados (usamos convenções -api e -core + Maven + verificação estática e de tempo de execução e pode até mesmo ir ao OSGi um dia para inicializar).

O que isso economiza? Bem, não temos que emitir várias solicitações de pull se estivermos mudando algo pequeno em vários projetos. Questões e Wiki são mantidos centralizados, etc.

Ainda tratamos cada módulo / projeto como um projeto independente adequado e os construímos e integramos separadamente em nosso servidor de CI, etc.

Para mim, a principal diferença em usar um ou mais de um repositório são as respostas para as seguintes perguntas:

• As várias partes desenvolvidas pela mesma equipe têm o mesmo ciclo de lançamento, o mesmo cliente? Então, há menos razões para dividir o único repositório.
• As várias partes são altamente dependentes umas das outras? Então dividir modelo, controlador e interface do usuário (mesmo quando eles são partes diferentes) não é muito sensível, devido à alta dependência entre si. Mas, se duas partes tiverem apenas uma pequena dependência, que é implementada por uma interface estável que é alterada apenas a cada poucos anos, seria sensato dividir as duas partes em dois repositórios.

Apenas como exemplo, eu tenho um pequeno aplicativo (somente cliente), que verifica a "qualidade" de um repositório do Subversion. Há a implementação principal, que pode ser iniciada a partir da linha de comando, e funciona bem com o Java 6. Mas comecei a implementar uma UI, que usa o JavaFX como parte do Java 8. Então, dividi o 2 e criei um segundo repositório (com um segundo processo de compilação), com horário diferente, ...

Eu gosto das respostas acima (votei nelas), mas acho que elas não são toda a história verdadeira. Então eu queria adicionar os argumentos para dividir os repositórios também. Então a verdadeira resposta (quando dividir) pode estar em algum lugar no meio ...

Pode ser que git-subtree (veja , blog médio , ou link do kernel seria uma boa opção para você. Assim, cada um dos seus projetos de nível superior usaria um conjunto de subárvore em versões possivelmente diferentes.