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:
-
É 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. -
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 digitartig --grep=<caseID>
ougit 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. - 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.