Usando las herramientas para Git de VS2012

Muy buenas! En este post voy a contar (o al menos intentarlo) como usar las herramientas de Git para VS2012 y trabajar con un repositorio Git instalado en TFS Services.

Nota: Este post está muy orientado a gente que viene de TFS, está acostumbrada a TFS y se siente un poco “perdida” con esto de Git. No pretende ser, ni mucho menos, un tutorial de Git.

Requerimientos previos

Debes tener instalado VS2012 y al menos el Update 2. Ve a la página de Updates de VS2012 para descargarte el último update (en la actualidad es el 3).

Una vez tengas el VS2012 actualizado, debes instalarte las herramientas para Git de VS2012, que te puedes descargar desde el gestor de extensiones de VS2012 o bien desde la propia página de las Visual Studio Tools for Git.

Finalmente debes tener una cuenta de TFS Services, que te puedes abrir en http://tfs.visualstudio.com. Abrir una cuenta es totalmente gratuito y te da acceso a un TFS listo para 5 usuarios de forma totalmente gratuita.

Antes que nada: diferencias entre Git y TFS clásico

El control de código fuente clásico de TFS es lo que se conoce como un CVS (Concurrent Version System), mientras que Git es un DCVS (Distributed Concurrent Version System). En TFS está claro quien es el servidor: te connectas a un servidor TFS, te bajas código de él y subes código en él.

Con Git, cada máquina es también un repositorio de código fuente. Vas a tener tu propio repositorio de código fuente en local. No tendrás solo “la última versión” si no todo el control de código fuente. Esto hace que operaciones como Branch o Merge sean mega rápidas (y puedas hacerlas offline).

De hecho, no hay en Git, un flujo que obligue a que haya un “servidor de Git centralizado”: puedes tener varios repositorios remotos con los cuales te sincronizas.

De todos modos, dado que es bastante habitual un flujo donde haya un servidor Git “central”, este es el que veremos en este post. En nuestro caso este “servidor git central” será TFS Services con el control de código fuente Git habilitado.

En Git no hay check-in o check-out, ni tampoco lock. En su lugar las operaciones básicas que tenemos son:

  1. Commit: Pasa cambios de tu working folder a tu repositorio git local pero NO al remoto.
  2. Push: Pasa cambios de tu repositorio git local al remoto
  3. Pull: Pasa cambios del repositorio git remoto al local y a la working folder.

Ahora sí…. empecemos.

Primer paso: Crear el team project

Para tener un repositorio Git en TFS debemos tener un team project. Así que dale al botón “New Team Project” desde la página principal de TFS Services y en las propiedades del proyecto asegúrate de seleccionar Git como gestor de código fuente:

image

Una vez tengas el team project creado estás listo para empezar a trabajar con Git.

Añadir la solución al control de código duente.

Para ello desde el solution explorer seleccionamos la opción “Add solution to Source control”. VS2012 nos preguntará si deseamos usar Git o bien el control de código fuente de TFS. Hasta ahora simplemente habíamos creado un repositorio de Git, pero no le habíamos indicado a VS2012 que íbamos a usarlo en nuestra solución:

image

Asegúrate de marcar la opción de Git y dale a Ok. Ahora si que estamos listos para hacer commits.

Al marcar la opción de Git, VS2012 nos crea un repositorio de Git local que está en el mismo directorio que nuestra solución. De hecho si abres con el explorador de archivos la carpeta de la solución, verás una carpeta oculta, llamada .git que es la que contiene el repositorio local.

Commit

Vamos a guardar nuestro código o en el repositorio de Git local. A diferencia del TFS clásico en Git no se protegen o desprotegen ficheros, así que no hay opciones de check-in o check-out. Básicamente Git mira todos los cambios que se producen entre la working folder y el repositorio Git local y son los ficheros que tengan cambios (de cualquier tipo) los que podemos “commitear” y enviar al repositorio Git local. Para hacerlo vete a la página inicial del team explorer pulsando el icono de home:

image

 

Ahora pulsa sobre de “Changes”. Con eso VS2012 te mostrará todos los archivos de la working folder que tengan algún cambio respecto al repositorio de Git local (es decir que se hayan añadido, borrado o modificado).

image

 

Los ficheros que aparecen en Included Changes son los ficheros que se incluirán en el commit. Los que aparecen en Excluded Changes son los que no se incluirán en el commit. Puedes pasar ficheros de un sitio a otro arrastrándolos. Una vez tengas el commit listo, debes añadir un mensaje de commit y ya podrás darle al botón “Commit”.

Una vez lo hayas hecho VS2012 te mostrará un mensaje diciendo que el commit ha sido correcto y continuarás en la misma página de commits, para seguir haciendo commits si quedan ficheros con cambios (es decir, ficheros que antes habías colocado en “Excluded Changes”). Eso es así porque con Git es costumbre hacer muchos commits y muy pequeños.

Push

Si ahora vuelves a la página inicial del Team Explorer (con el icono de la casita) y pulsas sobre el enlace “Commits” te aparecerá una ventana como la que sigue:

image

VS2012 nos pide que repositorio Git va a ser el remoto. Este debe estar vacío. Recuerda que antes hemos creado uno en TFS Services, pero todavía no habíamos dicho en ningún sitio que queríamos usarlo. Ahora ha llegado el momento. Copia la URL del repositorio Git remoto (la puedes encontrar en la página de TFS Services si vas al team project creado y al apartado “Code”) y dale al botón “Publish”. Con este proceso asociarás tu repositorio de Git local con el repositorio de Git remoto y además harás un push de los commits pendientes (es decir pasarás el código de tu repositorio Git local al remoto).

Cuando haya terminado te aparecerá una página parecida a:

image

¡Felicidades! Ya tienes un repositorio de Git local y remoto enlazado a tu solución.

Veamos ahora como añadir un cambio.

Para ello modifica un par de archivos del proyecto. Puedes hacerlo directamente: recuerda, olvida el concepto de check-out (desproteger). Vete a la página de Changes del team explorer (ve a la página principal a través del icono de casa y luego pulsa en Changes) y te aparecerán los dos archivos modificados:

image 

Arrastra uno de los dos a Excluded Changes, añade un mensaje de commit y dale a commit. Te aparecerá una pantalla como la siguiente:

image

Ahora arrastra el otro archivo a Included Changes, pon otro comentario y dale a commit de nuevo. Con esto has generado dos commits en el repositorio git local.

 

Si ahora te vas a la página de Push (vete a la inicial con el icono de la casa) y dale Commits (debajo de Changes) verás algo parecido a:

image

En outgoing commits te aparecerán los commits que has hecho en el repositorio local y que no están en el repositorio remoto. Si le das a “Push” subirás los cambios (los commits) desde el repositorio local al remoto.

Obtener los cambios de otro usuario

Vale, a no ser que estés tu solo en un proyecto (y sí, si estás tu solo en un proyecto te recomiendo encarecidamente también usar control de código fuente) en algún momento deberás incorporar los cambios que hay en el repositorio remoto al tu repositorio local.

Vete a la página de commits del team explorer (ya sabes, desde la home le das al enlace de Commits):

image

Debajo de “Incoming Commits” hay dos opciones:

  1. Fetch: Te permite obtener el listado de cambios que tienes pendientes de integrar. Es decir, el listado de commits que están en el repositorio remoto pero NO en tu repositorio local.
  2. Pull: Se trae los commits desde el repositorio remoto al repositorio local y actualiza la working folder.

Si le das a Pull el proceso es automático (Git se trae los commits del repositorio remoto al local y desde el local hacia la working folder resolviendo los conflictos si hiciese falta).

Si le das a Fetch, te aparecerán los commits que existen en el repositorio remoto, pero están pendientes de ser integrados a tu repositorio local:

image

Viendo los detalles de un commit

A veces, antes de integrar el código del repositorio remoto (es decir, antes de hacer pull) te interesa ver como este commit puede afectar a tu trabajo. Para ello, una vez has obtenidos los commits pendientes de integrar (es decir, una vez has hecho fetch) puedes ver los detalles de un commit pulsando con el botón derecho sobre él y seleccionando la opción “View Commit Details”:

image

Esto te permite ver los ficheros que conforman el commit, ver su contenido y compararlo con la versión anterior de este mismo fichero.

Resolviendo conflictos.

Imagina la situación en que tienes modificado un fichero en tu carpeta local pero NO has hecho commit de este fichero en tu repositorio git local. Imagina que haces pull y hay un commit que tiene este fichero modificado.

Cuando esto ocurrer recibirás el siguiente mensaje de error:

image

Si te aparece este mensaje debes primero hacer commit de tus cambios pendientes en tu repositorio Git local. Una vez hayas hecho el commit (no es necesario que hagas el push hacia el repositorio remoto) ya puedes volver a hacer el pull.

Entonces, Git intentará hacer merge automático entre el contenido de tu repositorio local y los commits que vienen del repositorio remoto). Pero puede que el merge automático no sea posible:

image

Nota: En esta pantalla “Incoming Commits” son los dos commits que estoy intentando integrar y en “Outgoing Commits” hay el commit que he hecho para colocar los cambios de la carpeta local hacia mi repositorio remoto. Como solo he hecho commit pero no push, por eso me aparece aquí.

Ahora pulsas sobre el enlace “Resolve the conflicts” y te aparece la página de resolución de conflictos:

image

Pulsando sobre cada uno de los archivos en “Conflicts” tendremos las opciones clásicas de tomar el archivo local (el de nuestro repositorio Git local), el remoto (el del repositorio Git remoto) o combinarlos:

image

Si le damos a “Merge” nos aparecerá la clásica ventana de Merge:

image

 

 

 

Una vez hayamos resuelto todos los conflictos, aceptamos el merge y repetimos la operación por todos los archivos. Al final llegaremos a una página parecida a:

image

Donde no habrá nada en “Conflicts” y todo estará en “Resolved”. Ahora tenemos estos cambios en nuestra working folder, pero NO en nuestro repositorio local de Git (y mucho menos en el remoto obviamente). Así que le damos a “Commit Merge” para pasar estos cambios de nuestra working folder a nuestro repositorio Gi local. Al hacerlo iréis a la página de Changes con el commit listo para ser enviado al repositorio local:

image

Fíjate que el commit que se me ha creado incluye tanto el archivo Program.cs (que es el que tenía conflictos) como el archivo App.config que pertenecía al otro “incoming commit”.

Una vez le deis a commit ya lo tendréis en el repositorio git local.

Finalmente os vais a la página de “Commits” y vereis los commits pendientes de integrar hacia el repositorio remoto (es decir, pendientes de hacer push):

image

Ahora puedes hacer push sin ningún problema y tu código integrado ya está en el reposiorio Git remoto.

Conclusiones finales

Cuando se trabaja en Git, no se trabaja a nivel de fichero, como con el control de código fuente clásico de TFS, si no que trabajamos a nivel de commit.

Debido a esto, haz commits pequeños.

Recuerda siempre el concepto de que hay un repositorio Git local y otro de remoto. A diferencia del control de código fuente clásico de TFS donde solo hay el remoto.

Si intentas hacer pull y tienes algún fichero modificado en tu working folder (del cual no has hecho commit hacia tu repositorio local) que está incluído en los commits que vas a integrar desde el servidor remoto, te dará error y deberás hacer primero un commit de este fichero (es decir pasarlo a tu repositorio local).

Espero que con esto os quede un poco más claro como funciona Git usando esta extensión de VS2012.

Finalmente: esta extensión no es, ni de lejos, el mejor cliente Git para Windows. Para flujos sencillos funciona bien, ya que está integrada en Visual Studio, pero para flujos de trabajo más complejos se queda corta. En estos casos es mejor usar un cliente de Git específico como SoureTree.

Saludos!

[Editado 20/07/2013] – Corregido un error (mirar comentario de Enrique Ortuño).

 

3 comentarios en “Usando las herramientas para Git de VS2012”

  1. Hola Eduard, excelente articulo, una simple observacion, en la frase:
    “Con eso VS2012 te mostrará todos los archivos de la working folder que tengan algún cambio respecto al repositorio de Git remoto”

    no te referias al Git Local?

    Un abrazo!

  2. @Enrique:
    Sí!!! Me refería al Git local. Gracias!! Ahora lo corrijo! 🙂

    @Unai
    No conocía posh-git!! Yo, la verdad, suelo usar SourceTree o la línea de comandos de Git directamente para según que!
    Pero le echaré un vistazo!!!! Gracias!

    Muchas gracias por comentar!!! 🙂

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *