Subrepositórios (submódulos) como uma solução de rastreamento de dependência - sim ou não?

Se você tiver a opção, vá com uma ferramenta dedicada em vez de usar o SCM para isso. Eu tenho escrito sobre isso em SO , mas o argumento se resume ao acoplamento, em particular acoplamento muito strong O desenvolvimento flexível de software tem tudo a ver com evitar acoplamentos apertados, a menos que seja realmente necessário e ambos os subrepositórios Mercurial e os submódulos Git introduzam um acoplamento muito strong.

Além disso, os subrepos / submódulos introduzem complexidade extra no fluxo de trabalho diário. Se as pessoas já estão familiarizadas com o SCM, isso pode ser aceitável. Mas eu vi muitas organizações onde eles tentam introduzir os sub-posicionamentos Mercurial e ao mesmo tempo - eu considero isso um erro, uma vez que isso faz tudo parecer mais complicado.

O wiki do Mercurial tem um conjunto de recomendações sobre como os sub-interesses devem ser usados. Estes incluem o uso de um repositório thin shell. Isso evita o acoplamento dos componentes juntos. Você pode trabalhar em qualquer subrepo conforme necessário e pressionar / puxar para atualizá-los. De vez em quando, alguém (talvez um engenheiro de desenvolvimento, talvez um servidor de integração contínua) testará novas configurações dos componentes. Se eles passarem nos testes, um novo commit será feito no repositório do shell para que as pessoas tenham uma nova base para usar em seu trabalho.

Quando mudamos do SVN para o Kiln (Mercurial) há um ano, reimplementamos nossos subrepositórios também. Eu posso honestamente dizer que gostaria de não ter. Os subrepositórios rapidamente se tornam um incômodo para lidar com mantê-los atualizados quando as dependências mudam. Isso é especialmente verdadeiro quando se lida com bibliotecas internas de "terceira parte" que estão sob desenvolvimento ativo.

No momento, estamos convertendo gradualmente nossas dependências para serem pacotes do NuGet criados e hospedados pelo nosso servidor TeamCity.

Antes que eu pudesse recomendar subrepositórios como uma escolha de solução preferida, eu precisaria ver um bom argumento em seu favor.

Eu uso o Mercurial e uso subrepositórios para todas as minhas dependências (GLEW, GLM, Boost, Assimp, Bullet), mas não estou convencido de que é sempre uma coisa boa. Às vezes, acho que faz mais sentido apenas vincular-se a uma biblioteca pré-criada.

Para mim, é bom poder compilar e analisar todo o código externo que estou usando para depuração, além de poder criar minhas próprias ramificações para fazer alterações personalizadas e ainda obter atualizações para meus subrepositórios.

Eu mantenho todos os meus subrepositórios em um diretório de Dependências logo abaixo da raiz do projeto, embora os documentos do Mercurial recomendem um repositório principal com seu próprio projeto e quaisquer dependências como subrepositórios.

git submodules são ótimos para isso. Ele permite que você mantenha todo o seu código em um pacote, atualize com simplicidade, faça isso por projeto, não se preocupe com os outros e basicamente mantenha tudo em ordem.

Algumas ressalvas:

1. git pull && git submodule init && git submodule update --- eles precisam fazer parte do fluxo de trabalho STANDARD.

2. Submódulos são difíceis se as pessoas estiverem alterando-os, resultando em conflitos. Não é muito difícil, mas tudo que você tem são dois SHA1 e você tem que escolher o melhor, ou mesclá-los manualmente e atualizar o repositório base.

3. O Github é um ótimo lugar para colocar todas as suas coisas no git. Isso é apenas uma observação, mas eu uso uma mistura de repositórios públicos para submódulos de código aberto e repouso privado para o projeto principal.

Espero que isso ajude!