Usando Git con Visual Studio

Como un usuario de Visual SourceSafe desde hace mucho time (y odiador) estaba discutiendo cambiar a SVN con un colega; sugirió usar Git en su lugar. Dado que, aparentemente, se puede usar como peer-to-peer sin un server central (solo tenemos un equipo de 3 desarrolladores).

Sin embargo, no he podido encontrar nada sobre las herramientas que integran Git con Visual Studio. ¿Existe tal cosa?

¿Qué tecnologías están disponibles para usar Git con Visual Studio? ¿Y qué necesito saber sobre cómo difieren antes de comenzar?

En enero de 2013, Microsoft anunció que están agregando soporte completo de Git en todos sus productos ALM. Han publicado un complemento para Visual Studio 2012 que agrega integración de control de fuente Git.

Alternativamente, hay un proyecto llamado Git Extensions que incluye complementos para Visual Studio 2005, 2008, 2010 y 2012, así como también la integración de Windows Explorer. Se actualiza regularmente y después de haberlo usado en un par de proyectos, lo encontré muy útil.

Otra opción es Git Source Control Provider .

Uso Git con Visual Studio para mi puerto de Protocol Buffers a C #. No uso la GUI, solo mantengo una command-line abierta, así como Visual Studio.

En general, está bien, el único problema es cuando quieres renombrar un file. Tanto Git como Visual Studio preferirían que fueran ellos quienes le cambiaran el nombre. Creo que el cambio de nombre en Visual Studio es el path a seguir, solo ten cuidado con lo que haces en el lado de Git después. Aunque esto ha sido un poco molesto en el pasado, escuché que en realidad debería ser bastante fluido en el lado de Git, porque puede notar que el contenido será casi el mismo. (No es lo mismo, por lo general, tiendes a cambiar el nombre de un file cuando cambias el nombre de la class, IME).

Pero, básicamente, sí, funciona bien. Soy un novato de Git, pero puedo hacer que haga todo lo que necesito. Asegúrese de tener un file de ignorar git para bin y obj, y * .user.

Git Source Control Provider es un nuevo complemento que integra Git con Visual Studio.

He analizado esto un poco en el trabajo (tanto con Subversion como con Git). Visual Studio en realidad tiene una API de integración de control de origen que le permite integrar soluciones de control de origen de terceros en Visual Studio. Sin embargo, la mayoría de las personas no se molestan por un par de razones.

La primera es que la API asume que estás utilizando un flujo de trabajo de pago bloqueado. Existen muchos enganches que son costosos de implementar o simplemente no tienen sentido cuando se usa el flujo de trabajo de fusión de edición más moderno.

El segundo (que está relacionado) es que cuando utilizas el flujo de trabajo de fusión de edición que alientan tanto Subversion como Git, realmente no necesitas la integración de Visual Studio. Lo principal de la integración de SourceSafe con Visual Studio es que usted (y el editor) pueden saber de un vistazo cuáles son sus files, que deben ser revisados ​​antes de poder editarlos, y que no puede revisar, incluso si lo desea. Luego puede ayudarlo a hacer cualquier vudú de control de revisiones que necesite hacer cuando quiera editar un file. Nada de eso es parte de un flujo de trabajo típico de Git.

Cuando usa Git (o SVN por lo general), todas las interacciones de control de revisiones tienen lugar antes de su session de desarrollo o después (una vez que tiene todo funcionando y probado). En ese punto, realmente no es demasiado doloroso usar una herramienta diferente. No tienes que cambiar constantemente de un lado a otro.

Encuentro que Git, trabajando en treees integers como lo hace, se beneficia less de la integración IDE que las herramientas de control de origen que se basan en files o siguen un patrón de checkout-edit-commit. Por supuesto, hay casos en que puede ser agradable hacer clic en un button para realizar un examen de historia, pero no extraño mucho.

Lo que realmente debe hacer es get su file .gitignore lleno de las cosas que no deberían estar en un repository compartido. Los míos generalmente contienen (entre otras cosas) lo siguiente:

*.vcproj.*.user *.ncb *.aps *.suo 

pero esto está fuertemente sesgado por C ++ con poco o ningún uso de cualquier funcionalidad de estilo de asistente de class.

Mi patrón de uso es algo como lo siguiente.

  1. Código, código, código en Visual Studio.

  2. Cuando esté contento (punto intermedio sensible para confirmar el código, cambie a Git, cambie la etapa y revise las diferencias. Si algo está obviamente mal, vuelva a Visual Studio y corrija; de lo contrario, confirme.

Cualquier combinación, sucursal, rebase u otras cosas sofisticadas de SCM es fácil de hacer en Git desde el símbolo del sistema. Visual Studio normalmente está bastante contento con las cosas que cambian debajo de él, aunque a veces puede necesitar volver a cargar algunos proyectos si ha alterado significativamente los files del proyecto.

Encuentro que la utilidad de Git supera cualquier inconveniente menor de no tener integración IDE completa, pero es, hasta cierto punto, una cuestión de gusto.

Microsoft anunció recientemente Git for Visual studio 2012 (actualización 2). Todavía no jugué con eso, pero este video parece prometedor.

Aquí hay un tutorial rápido sobre cómo usar Git de Visual Studio 2012.

Además, no te pierdas TortoiseGit … https://tortoisegit.org/

Hay una Visual Studio Tools para Git de Microsoft. Sin embargo, solo es compatible con Visual Studio 2012 (actualización 2).

Visual Studio 2013 es compatible nativamente con Git.

Ver el anuncio oficial .

El soporte de Git hecho por Microsoft en Visual Studio es lo suficientemente bueno para el trabajo básico (commit / fetch / merge y push). Mi consejo es solo evitarlo …

Yo prefiero GitExtensions (o en less proporción SourceTree ). Porque ver el DAG es realmente importante para mí para entender cómo funciona Git. ¡Y usted es mucho más consciente de lo que han hecho otros queueboradores de su proyecto!

En Visual Studio, no puede ver rápidamente la diferencia entre los files o confirmar, ni (agregar al índice) y comprometer solo una parte de las modificaciones. Navegar por su historial tampoco es bueno … ¡Todo eso termina en una experiencia dolorosa!

Y, por ejemplo, GitExtensions se incluye con complementos interesantes: búsqueda de background, GitFlow, … ¡y ahora, continuous integration !

Para los usuarios de Visual Studio 2015 , Git está tomando forma si instala la extensión GitHub. Pero una herramienta externa es aún mejor 😉

TortoiseGit ha madurado y lo recomiendo especialmente si ha usado TortoiseSVN.

La última versión de Git Extensions es compatible ahora con Visual Studio 2010 (junto con Visual Studio 2008 y Visual Studio 2005 ).

Me pareció bastante fácil de usar con Visual Studio 2008 y la interfaz parece ser la misma en Visual Studio 2010.

La solución más simple que realmente funciona bastante bien es agregar los commands de TortoiseGit como herramientas externas.

Solución para agregar una barra de herramientas de Git (TortoiseGit) a Visual Studio

Como lo menciona Jon Rimmer, puedes usar GitExtensions. GitExtensions funciona en Visual Studio 2005 y Visual Studio 2008, también funciona en Visual Studio 2010 si copy y configura manualmente el file .Addin.

Actualmente hay 2 opciones para Git Source Control en Visual Studio (2010 y 12):

  1. Proveedor de control de fuente Git
  2. Proveedor de Microsoft Git

He intentado ambos y he encontrado el primero para ser más maduro, y tiene más características. Por ejemplo, juega muy bien con las extensiones de tortuga git y git, e incluso expuso sus características.

Nota : Cualquiera que sea la extensión que use, asegúrese de habilitarla en Tools -> Options -> Source control -> Plugin Selection para que funcione.

A partir del 2013-02-11, el plugin de Microsoft Git para Visual Studio 2012 también debería funcionar con la versión Express .