Fluxo de trabalho para usar submódulos git no Visual Studio - git, visual-studio, visual-studio-2013, git-submodules

Eu tenho um código compartilhado que quero compartilhar entre várias soluções. A maioria dos exemplos usa a linha de comando, mas eu quero fazê-lo usando o Visual Studio 2013 (e / ou o TortoiseGit)?

- SolutionShared
- .git
- Project1Shared
- Project2Shared
- Solution1
- .git
- ProjectFoo
- ProjectBar
- [SolutionShared]
- [Project1Shared]
- [Project2Shared]
- Solution2
- .git
- ProjectBaz
- ProjectQux
- [SolutionShared]
- [Project1Shared]
- [Project2Shared]

O que eu fiz foi criar uma nova solução SolutionShared, adicione todo o meu código compartilhado e adicione-o ao seu próprio repositório do git. Então eu usei o TortoiseGit (como eu não conseguia descobrir como fazer isso com o Visual Studio) para adicionar esse repositório compartilhado como um submodule git para Solution1 e Solution2.

1. O que eu faço no Visual Studio?
Minhas duas soluções agora têm um SolutionShared diretório. Eu simplesmente adiciono seus dois projetos filhos (Project1Shared e Project2Sharedno Visual Studio?

2. Como faço alterações no código compartilhado a partir dos projetos não compartilhados?
Se eu estiver em uma das soluções não compartilhadas e fizer uma alteração em algo no submódulo, como posso confirmar e enviar de volta ao repositório da solução compartilhada (SolutionShared) para que esteja disponível para todas as soluções que o referenciam?

Respostas:

Depois de muita experimentação ...

No VS, adicione os projetos compartilhados do submódulo à solução. Eles parecem viver "fora" da solução pai no que diz respeito ao controle de versão.

Se você fizer uma edição nos projetos do submódulo,eles são locais. Eles precisam ser confirmados e enviados para o repositório de origem e, em seguida, você precisa mesclá-los lá. Se você fizer alterações na origem, precisará puxá-las manualmente para o submódulo git da sua solução.

O problema é que o VS não faz nada disso para você, então você precisa usar algo como o TortoiseGit ou a linha de comando.

Descobrimos que a maneira mais fácil de fazer isso é mover cada uma das nossas unidades de código compartilhadas para o próprio projeto do Visual Studio e colocar cada projeto compartilhado do Visual Studio em seu próprio repositório.

Nós adicionamos cada um desses projetos como umsubmódulo para qualquer solução que precise deles. Isso é útil, pois muitos de nossos projetos podem ser muito grandes e compartilhar muitos dos mesmos trechos de código. Fizemos uso extensivo de pacotes nuget para esse propósito, mas, em geral, tivemos mais sucesso e uma experiência de design / depuração muito melhor com submódulos.

Muito mudou na Microsoft em relação ao Gitnos últimos anos. O Visual Studio Team Services (TFS Online) e o On-Prem TFS (desde o TFS2015) agora têm um bom entendimento de como os submodules funcionam e agora podem fazer CI Builds que incorporam submodules imediatamente.

Suporte no TFS 2015 on-prem pode ser um pouco buggy,Contudo. As referências do TFS Build aos submódulos têm o hábito de se corromper, resultando em compilações que param de funcionar sem aviso prévio, até que o submódulo defeituoso seja completamente removido e adicionado novamente - não um processo divertido. Por esse motivo (entre alguns outros) Agora estamos usando o VSTS (TFS Online) para tudo e não tivemos nenhum desses mesmos tipos de problemas, eu diria que isso também é corrigido no TFS 2017 on-prem.

Como foi mencionado, o próprio Visual Studio (o IDE)ainda tem dificuldade em entender os relacionamentos dos submodules. Ele realmente não pode lidar com eles. Eu tentei um número de Git Tools autônomo para encontrar a maneira mais fácil de gerenciar um ambiente como este. Tortoise parece fornecer a experiência mais fácil e mais performance ao empurrar, puxar e fazer check-in para repos. Eu costumo usar comandos para adicionar os submódulos, mas eu suspeito que a funcionalidade add submodule do Tortoise funciona muito bem também.

Quando você submete o código a um repo usando Tortoise,percebe quando um submódulo está sujo e solicitará que você faça o check-in no submódulo antes de fazer o check-in do repositório pai. Isso é muito bom. Puxar ou buscar o repositório pai pode ser um pouco confuso, porém. Na verdade, ele não atualiza o submódulo da ramificação remota, ele apenas o atualiza para qualquer nível que esteja atualmente marcado no repo principal remoto. que nem sempre é o mais recente.Na realidade, este é o comportamento desejado, não é apenas imediatamente intuitivo se você não está esperando isso.