submodulos - instalar git en visual studio code

Flujo de trabajo para usar submódulos de git en Visual Studio

Question

Tengo un código compartido que quiero compartir entre una serie de soluciones. La mayoría de los ejemplos usan la línea de comando, pero quiero hacerlo usando Visual Studio 2013 (y / o TortoiseGit)?

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

Lo que hice fue crear una nueva solución SolutionShared , agregar todo mi código compartido y agregarlo a su propio git repo. Luego utilicé TortoiseGit (ya que no pude entender cómo hacerlo Visual Studio) para agregar ese repositorio compartido como submódulo de git a Solution1 y Solution2 .

1. ¿Qué hago en Visual Studio?
Mis dos soluciones ahora tienen un directorio SolutionShared . ¿Simplemente agrego sus dos proyectos secundarios ( Project1Shared y Project2Shared ) en Visual Studio?

2. ¿Cómo realizo cambios en el código compartido dentro de los proyectos no compartidos?
Si estoy en una de las soluciones no compartidas y realizo un cambio en algo del submódulo, ¿cómo lo comprometo y lo vuelvo a enviar al repositorio de la solución compartida ( SolutionShared ) para que esté disponible para todas las soluciones que hacen referencia a él?

Answer 1

Después de mucho experimentar ...

En VS, agregue los proyectos compartidos desde el submódulo a la solución. Parecen vivir "fuera" de la solución principal en cuanto a las versiones.

Si realiza una edición de los proyectos del submódulo, son locales. Deben comprometerse y enviarse al repositorio de origen, y luego debe fusionarlos allí. Si realiza cambios en la fuente, debe extraerlos manualmente en el submódulo git de su solución.

El problema es que VS no hace nada de esto por ti, por lo que necesitas usar algo como TortoiseGit o la línea de comando.

Answer 2

Hemos descubierto que la forma más fácil de hacerlo es mover cada una de nuestras unidades compartidas de código en su propio Proyecto Visual Studio y poner cada proyecto compartido de Visual Studio en su propio repositorio.

Luego agregamos cada uno de esos proyectos como un submódulo a cualquier Solución que los necesite. Esto es útil ya que muchos de nuestros proyectos pueden ser de gran tamaño y compartir muchos de los mismos fragmentos de código. También hemos hecho un uso extensivo de los paquetes nuget para este propósito, pero en general hemos tenido un mejor éxito y una experiencia de diseño / depuración mucho mejor con los submódulos.

Mucho ha cambiado en Microsoft en relación con Git en los últimos años. Visual Studio Team Services (TFS Online) y Prem-TFS (desde TFS2015) ahora tienen una buena comprensión de cómo funcionan los submódulos y ahora pueden hacer compilaciones de CI que incorporan submódulos desde el primer momento.

Sin embargo, el soporte en TFS 2015 premier puede ser un poco problemático. Las referencias de TFS Build a los submódulos tienen la costumbre de corromperse, lo que da como resultado construcciones que dejan de funcionar sin previo aviso hasta que el submódulo tiene la culpa se elimina por completo y se vuelve a agregar, lo que no es un proceso divertido. Por esta razón (entre algunas otras), ahora estamos usando VSTS (TFS Online) para todo y no hemos tenido ninguno de esos mismos tipos de problemas. Asumiría que esto también está arreglado en TFS 2017 en las instalaciones.

Como se mencionó, a Visual Studio en sí mismo (el IDE) todavía le cuesta entender las relaciones de los submódulos. Realmente no puede manejarlos. He intentado varias herramientas independientes de Git para encontrar la manera más fácil de administrar un entorno como este. Tortoise parece proporcionar la experiencia más fácil y más efectiva al empujar, tirar y registrar repos que contiene submódulos. Usualmente uso comandos para agregar los submódulos, pero sospecho que la funcionalidad de agregar submódulos de Tortoise también funciona bien.

Cuando se ingresa el código en un repositorio utilizando Tortoise, se da cuenta de que un submódulo está sucio y le solicita que registre el submódulo antes de verificar en el repositorio principal. Eso es muy agradable. Sin embargo, tirar o recuperar el repositorio padre puede ser un poco confuso. En realidad, no actualiza el submódulo desde su rama remota, solo lo actualiza a cualquier nivel que esté actualmente registrado en el control remoto de repositorio principal, que no siempre es el último. En realidad, este es el comportamiento deseado, simplemente no es inmediatamente intuitivo si no lo estás esperando.