Git para dummies (pero dummies, dummies eh?)

Disclaimer: Ese post ni es, ni lo pretende, ser un tutorial de Git. Es simplemente las impresiones de alguien (yo) que ayer empezó a usar, por primera vez, Git. Seguro que hay gente que lee ese blog y que sabe mucho, pero mucho más de Git que yo… Así que sus comentarios y correciones serán bienvenidas! 🙂

Esos días (ayer, vamos :p) he empezado a usar Git. Para quien no lo conozca Git es un sistema de control de código fuente distribuído. A diferencia de TFS, VSS o SVN que son centralizados, en Git cada desarrollador tiene su propia copia entera del repositorio en local. Los cambios son propagados entre repositorios locales y pueden (o no) sincronizarse con un repositorio central.

La diferencia fundamental con TFS ó VSS es que en esos está claro quien es el repositorio (el servidor). Eso no existe en Git. En Git cada usuario es el repositorio y se sincronizan cambios entre repositorios (usuarios). Opcionalmente puede usarse un repositorio central pero parece que no es obligatorio.

Los cambios en Git se propagan a través de esas operaciones:

  1. commit: Envia los datos del working directory al repositorio local
  2. push: Sincroniza los cambios del repositorio local a otro repositorio remoto.
  3. fetch: Sincroniza los cambios de un repositorio remoto al repositorio local.
  4. pull: Sincroniza los cambios de un repositorio remoto al working directory.
  5. checkout: Actualiza el workind directory con los datos del repositorio local.

La siguiente imagen lo clarifica bastante:Comandos de transporte de Git

Operaciones de Git (imagen original de Oliver Steele en http://www.gitready.com/beginner/2009/01/21/pushing-and-pulling.html).

Usar Git desde Visual Studio

Para usar Git desde VS2010 he encontrado las Git Extensions que instalan, no sólo un plugin para VS2010, sinó también el propio Git y clientes adicionales que pueden necesitarse (SSH o PuTTY si queremos conexiones seguras con nuestros repositorios).

Una vez instaladas nos aparecerá un menú nuevo llamado “Git” en el VS2010.

Crear un repositorio local y rellenarlo

Para empezar a trabajar con Git, lo primero es crear un repositorio. Recordad que los repositorios son locales, por lo que un repositorio es simplemente un directorio de nuestro disco. En mi caso, tenía ya una solución de VS2010 en local que es la que quería empezar a compartir con Git. Por ello lo que hice fue crear un nuevo repositorio local. Hay otra opción, que es crear un repositorio local a partir de los datos de un repositorio remoto (git-clone) pero todavía no lo he hecho. Si todo va como está planeado, el viernes tocará hacerlo, y ya escribiré al respecto!

Usando las Git Extensions crearnos nuestro propio repositorio es tan sencillo como usar la opción “Initialize new repository” y nos saldrá una ventana como la siguiente:

image

La opción normal es “Personal repository”. Un Central repository es un repositorio sin Working directory, que sólo sirve para sincronizar datos.

Una vez entrada la carpeta (en este caso D:Gittest) esa pasa a ser el directorio de trabajo (working directory) para ese repositorio. Si abrimos la carpeta con el explorador de windows veremos que hay una carpeta en su interior llamada .git: ese es el repositorio local.

Nota: Dado que el directorio donde inicializamos el repositorio local pasa a ser el directorio de tabajo, lo suyo es inicializar el repositorio local en el mismo directorio donde tenemos la solución de VS. Es decir, si la solución de VS la tenemos en el directorio C:projectssourcemyproject, ese sería el directorio que usariamos (recordad que el repositorio se crea en una subcarpeta llamada .git, por lo que no modificarà ni borrará nada de la carpeta que le digáis).

En mi caso en D:Gittest ya tenía una solución, por lo que el árbol de directorios me ha quedado:

image

Ahora vamos a hacer commit de la solución al repositorio local. Antes que nada, pero debemos tener presente de que no queremos que todos los archivos que cuelgan del working directory (D:gittest) se guarden en el repositorio local. Git no entiende de tipos de archivo, no sabe que es código fuente y que no. Existe un fichero en el working directory llamado .gitignore que sirve para indicar que ficheros no deben guardarse en el repositorio local al hacer un commit.

Por suerte editar este fichero con las Git Exensions, es trivial. Nos vamos al menú Git y seleccionamos “Edit .gitignore”. Nos aparecerá una ventana parecida a:

image

A la izquierda el contenido del .gitignore (en este caso vacío, normal ya que ni existe el fichero). A la derecha un ejemplo de .gitignore adaptado a VS. Si pulsais el botón “add default” os copiará las entradas de la derecha a la izquierda:

image

Fijaos que el .gitignore se ha confiugrado para evitar archivos como *.exe, *.pdb, etc, pero también directorios como TestResult* (que usa VS para guardar los resultados de las pruebas unitarias) o _Resharper* (que usa resharper para guardar sus configuraciones). Nosotros podríamos añadir más entradas y finalmente darle a “Save”. Eso nos creará el archivo .gitignore en nuestro working directory (D:gittest).

Ahora estamos listos para hacer el commit y rellenar por primera vez el repositorio local. Para ello, de nuevo nos vamos al menú Git y seleccionamos “Commit”. Nos aparecerá una ventana parecida a:

image

Se divide en cuatro secciones:

  1. Izquierda superior: listado de operaciones pendientes de realizar (cambios entre el working directory y el repositorio local)
  2. Izquierda inferior: listado de operaciones que se van a realizar (es decir cuales de los cambios del working directory queremos propagar al repositorio local).
  3. Derecha superior: preview del archivo seleccionado en la parte (1).
  4. Derecha inferior: comandos de Git.

En este caso vamos a propagar todos los cambios, para ello pulsamos el botón “Staged Files” y en el menú desplegable marcamos “Stage all”. Con eso todos los ficheros de la izquierda superior pasarán a la izquiera inferior. Ahora vamos a realizar el commit (si quisieramos podríamos hacer también un push a un repositorio remoto pero todavía no hemos configurado ninguno).  Así que entramos un mensaje de commit en la parte derecha inferior (p.ej. commit inicial) y le damos al botón “Commit”. Git Extensions nos mostrará al final un diálogo con el resumen de lo hecho:

image

Añadir cambios

Bien, una vez hemos hecho el commit podemos seguir trabajando con VS2010 sin necesidad de hacer nada especial. Olvidaros de conceptos como “proteger” o “desproteger” de TFS o VSS. Simplemente trabajáis y modificáis el contenido del directorio de trabajo.

Cuando decidáis propagar los cambios del directorio de trabajo al repositorio local, repetís la operación de antes: Git –> Commit.

Repositorio remoto

Bien, ha llegado la hora de configurar un repositorio remoto. Para ello, lo primero que necesitamos es tener acceso a un repositorio remoto. Hay varios proveedores de repositorios Git en internet, entre los que destaca GitHub. GitHub pero está limitado a proyectos open source. Si neceistáis un hosting de Git para proyectos no open source hay varios de pago (con algunas versiones gratuitas). En esta consulta de StackOverflow hablan de ello: Best git repository hosting for commercial project.

Nota: A título informativo os diré que yo me dí de alta en el plan gratuito de Assembla, que te da 2GB de espacio Git.

La configuración de un repositorio remoto dependerá de donde lo tengamos, pero básicamente son dos pasos muy simples:

  1. Generar el par clave pública-privada para ssh o PuTTY y subir la clave pública al repositorio (si queremos acceso seguro).
  2. Ponerle a Git Extensions la URL del repositorio remoto.

Vamos a ver una demostración. Para independizarnos de cualquier proveedor, vamos a crear otro repositorio de Git en nuestra máquina (podríamos hacerlo en una carpeta compartida p.ej.) y lo usaremos como repositorio remoto.

Para ello de nuevo nos vamos al menú Git y le damos a “Initialize new repository” y ahora marcamos la opción de Central Repository. Y ponemos cualquier path nuevo que creemos (en mi caso he creado una carpeta D:Remote):

image

Si ahora vamos a D:Remote veremos que allí tenemos el repositorio. En este caso el repositorio no está en un subdirectorio .git, porque hemos elegido la opción de Central repository que no tiene directorio de trabajo.

Bien, ahora vamos a hacer un push de nuestro repositorio local al repositorio remoto. Para ello, primero, debemos dar de alta este repositorio remoto en las Git Extensions. Para ello nos vamos al menú Git y seleccionamos la opción de “Manage Remotes”. Nos aparecerá una ventana y ponemos los datos:

image

El nombre es un nombre identificativo, mientras que la URL en este caso es la carpeta donde está el repositorio. Finalmente le damos a “Save” para guardarlo.

Ahora ya podemos hacer un push para pasar los datos del repositorio local al remoto. Para ello, de nuevo nos vamos al menú Git y marcamos la opción Push. En la ventana que nos aparece marcamos la opción “Remote” y de la combo seleccionamos el repositorio remoto que dimos antes de alta:

image

Luego pulsamos el botón Push. Como antes nos mostrará un diálogo cuando haya finalizado:

image

Navegar por repositorios

Podemos navegar por un repositorio, usando la opción “Browse” del menú Git. Seleccionamos el repositorio y podemos navegar, ver los commits/push que se han realizado y ver los archivos y cambios contenidos en cada commit/push. De todos modos sólo he visto como hacer esto en repositorios (locales o remotos) que estén en disco. No sé como navegar por mi repositorio en Assembla p.ej.

image

Y aquí lo dejamos por el momento… A medida que trabaje y que vaya aprendiendo como funciona Git iré poniendo más información al respecto!

Espero que este post os haya sido útil y que en todo caso haya servido para que veáis que es Git y las diferencias con otros sistemas de control de código fuente como TFS.

Un saludo!

21 comentarios sobre “Git para dummies (pero dummies, dummies eh?)”

  1. @Tutle
    Gracias por tu comentario!! 😀
    La verdad NO sabía que había un Tortoise para Git! 😉

    Aunque las Git Extensions también tienen integración con el Shell (al menos salen cosas en el menú contextual :p) y pueden ejecutarse fuera de VS2010… A ver si saco tiempo y le puedo dedicar un post!

    Un saludo!

  2. Hola Eduardo, no quiero iniciar un debate sobre si Git o Mercurial es mejor, pero ¿cuales fueron tus motivaciones personales para preferir Git en vez de Mercurial?.

    Saludos

  3. Hola Arturo!

    Pues muy simple: Nada técnico.

    Simplemente tengo un proyecto personal (una parte será open source, pero hay otra que no) que compartimos entre varias personas y necesitábamos un control de código fuente, para empezar a sincronizarnos.

    Total, que busqué y encontré un par de sitios donde me ofrecían repositorios privados de Git de forma gratuita y no los encontré para Mercurial (también los encontré para SVN pero puestos a elegir preferí Git para aprender algo nuevo).
    Y como Git no tiene mala fama y he oído de otra gente que lo usaba, pues me lancé al ruedo…

    Si sabes de algún sitio donde ofrezcan hostings de Mercurial, me lo miraré sin duda para aprenderlo. En estos temas considero que cuantas más experiencias se tengan, mucho mejor!

    Muchas gracias por comentar!!! 😉

    PD: Y si consideras que Mercurial es mejor que Git, por favor dí tus razones… 😀
    Yo la verdad, no podré opinar mucho, porque ya digo que Git lo aprendí ayer!!! :S

  4. Hola Eduard.

    kilnhg.com ofrece hosting gratuito para 2 personas.

    Al igual que tu, yo uso Mercurial porque es el único sistema de control de versiones distribuido que conozco. Y por el soporte gratuito que le dan para open source (osea mis trabajos de la universidad) sitios como CodePlex y Google Code.

    Voy a explorar Git siguiendo tus post.

    Saludos

  5. Excelente post !!! cuando hace un tiempo me tuve que pegar un poco con Git te juro que hubiese pagado por algo asi … excellent work !!! 😀

  6. Una pregunta…. (ni sabía que existiá esto del GIT hasta hoy) si esto se almacena en cada cliente, porqué son necesarios los «hostings gratuitos» que mencionas?

    Pensaba que la ventaja de esto, sería que no sería necesario un servidor, algo ideal para proyectos free time o amateur.

  7. Pues yo también llegué a probar Git hace poco debido a la necesidad de usar un repositorio privado sin caducidad (lástima que CodePlex no tenga esta alternativa aunque sea pagando) y lo sigo usando.

    La interfaz de la web es simple y no está nada mal la implementación de branching/merging, aunque cuando uno está acostumbrado a TFS echa de menos la integración que tiene con Visual Studio.

    Me pasa como a ti, que no conozco el Tortoise ni Mercurial. Les echaré un vistazo para poder tener opinión.

    Un saludo.

  8. Hola Jesús, los hosting gratuitos son útiles para tener un repositorio central donde varias personas del proyecto puedan publicar.

    Es cierto que el repositorio central también puede ser el repositorio que esta en mi computadora y otra persona hacer push o pull desde mi repositorio, pero eso conlleva tener siempre prendida mi pc. Ademas que si le entra un virus a mi pc, me quede sin nada.

    Saludos

  9. @Jesús
    Iba a decir lo mismo que @Arturo pero se me ha avanzado, jejejeee…
    Exactamente lo queremos para eso: repositorio central, siempre online para sincronizarnos entre todos los que participamos en el proyecto (que andamos por ahí desperdigados) 😉

    @davidjrh
    Mercurial no lo conozco (aunque le echaré un vistazo) y tortoise no es un control de código fuente: es un cliente. Yo lo conocía en su versión para SVN (TortoiseSVN) que se integra con el explorador de windows y te permite hacer checkouts y commits contra el SVN desde el propio explorador de Windows.
    Supongo que TortoiseGit debe seguir la misma filosofía (aunque he visto que las Git Extensions también se integran con el explorador).
    Sobre lo que comentas de la integración con VS, eso en TFS/VSS es necesario debido al concepto de «proteger» / «desproteger» que debes aplicar continuamente… súmalo a que un «item» de VS realmente son varios archivos y necesitas esta integración sí o sí.
    En Git se trabaja de forma mucho más desconectada, de forma que tu vas haciendo y al final actualizas el repositorio con los cambios que quieras. Por lo que, realmente, no es necesaria una integración tan fuerte con VS.

    @Bruno
    Algo había oído de CodePlex y Mercurial 😉
    De todos modos no he usado CodePlex porque el proyecto deonde estoy tiene un % que no es open source…

    Gracias a todos por vuestros comentarios!!! 😉

  10. @El Bruno,

    ¿pero repositorios privados? He probado la integración con TFS de CodePlex y va de perlas pero según tengo entendido es para repositorios públicos (tienes 30 días para publicarlo o es eliminado). No he visto otra opción.

  11. @Hadi,

    lo que dices es cierto. El Git GUI no muestra ni siquiera el progreso de upload que sí se muestra el Bash por línea de comandos. Cuando tienes que subir mucho no sabes si el GUI se ha colgado o está haciendo algo.

  12. @davidjrh pues si, en CodePlex son 30 días para «activar algo» y luego 100% público. CodePlex.org (ahora con otro nombre que no me acuerdo) daba otras opciones, pero no creo que sean las que vos necesitas.

    Salu2

  13. @Hadi
    Si, es probable lo que comentas de la línea de comandos… Ya iré contando por aquí mis experiencias con Git, porque creo que es algo que vale la pena que la gente conozca! 🙂

    @Crowley
    Gracias por compartir el enlace! Lo he estado ojeando y es muy buen aporte. Todavía no me he metido con el branching/merging de Git y no sé hasta que punto se diferencia del branching/merging de TFS, p.ej. Aunque, en lo que «discrepo» un poco del enlace es en que yo, personalmente, no creo que branching/merging en TFS sea algo «complicado» o «avanzado»…

    @A todos:
    Muchas gracias por vuestros comentarios y aportes! Se agradecen!!! 😀

  14. Llevo leido la mitad y quiero darte las gracias, porque con esta guia se quita el miedo de empezar ha montar el git y ha usarlo. Supongo que luego habra que pasar a aprender mas, pero el paso inicial da mucho vertigo y con tu ayuda esta siendo mucho mas seguro.
    Gracias de nuevo

  15. Creo que falta lo siguiente.
    Despues de instalar el plugin en visual studio, hay que ir a herramientas/opciones, seleccionar “source control” en la vista de arbol y desplegar la caja de lista “complemento de control de codigo fuente actual” y seleccionar “git source control provider”. Una vez que iniciemos nuestro repositorio (“Initialize new repository”) en la vista del explorador de soluciones, aparecera (master) a continuacion del nombre de la solucion, una opcion git en el menu contextual (boton derecho) para los fichero y solucion, asi como marcadores en nuestros ficheros parra saber el estado de nuestros ficheros con relacion al repositorio como estan nuestros ficheros.

  16. Otra cosita:
    Desde la ventana de dialogo de commit, y antes de «stage all» tuve que añadir el fichero .opensdf a .gitignore (boton derecho sobre el fichero y seleccionar «add file to .gitignore»).

Responder a anonymous Cancelar respuesta

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