Hace algún tiempo (4 añitos de nada) publiqué una receta para montar un repositorio SVN sobre SSH, poco después de descubrir Subversion.

Desde que tengo un MacBook y uso PCs con Linux un poco antiguos (2 años) me encuentro a menudo con el problema de que las copias locales no son compatibles entre ellos, una versión antigua (1.4) de Subversion no puede manejar una copia local de una versión más reciente (1.6). Dado que necesito usar la misma copia local en varios ordenadores, necesito una solución.

Mantener la misma versión de Subversion en cada ordenador no me parece una buena solución a largo plazo, es una solución volátil que se esfuma al cambiar de ordenador or reinstalarle el sistema operativo, que con el MacBook no es poco habitual. Volver a CVS sería como pegarme un tiro en los pies, así que se me ocurrió mirar hacia delante: Git.

Git es bastante distinto de Subversion, entre otras cosas me permite olvidarme de qué versión de Git uso en cada momento, pero además me permite guardar cambios e historial en la copia local, algo que con CVS o Subversion no es tan directo ;-)

En realidad hace algo más de 3 años que conozco git, pero lo tenía un poco abandonado. Recuerdo introducirlo en la Oficina de Software Libre de la Universidad de La Laguna cuando aún era algo relativamente nuevo y desconocido… también recuerdo el susto que nos llevamos un colega y yo cuando parecía que había borrado código suyo, que luego recuperé mágicamente del éter :D

No me voy a enrollar con los detalles, hay documentación a patadas en el sitio de Git si quieres saber más. Sólo apuntaré aquí los pasos necesarios para:

  1. Crear un repositorio local, a partir de un directorio donde asumo que ya hay contenido limpio, i.e. listo para publicar, aunque tampoco es necesario.
  2. Crear un repositorio remoto al que poder enviar los cambios en el repositorio local.
  3. Vincular ambos repositorios, enviando al remoto el contenido del local.
  4. Crear una copia local nueva a partir del respositorio remoto.
  5. Integrar los cambios, hechos en la nueva copia local, de vuelta al repositorio remoto.
  6. Recuperar esos cambios de vuelta al directorio (local) original.

Puedes encontrar algunas operacioens más en este tutorial en inglés, a mí me fue muy útil :)

Paso 0. Identificarse.

No es que sea necesario, pero Git no dejará de quedarse hasta que le digas cómo te llamas y cuál es tu email:

git config –global user.name "Pepito el de los Palotes"
git config –global user.email pepitopalotes.com

Paso 1. Crear el respositorio local.

Partimos de un directorio con al menos un fichero dentro, en este ejemplo voy a usar unos scripts que uso para automatizar post-procesado de imágenes.

cd Fotos/photo-scripts
git init
git add .
git commit -m 'Initial commit'

Paso 2. Crear un repositorio remoto.

Si tienes accesso SSH a un servidor Linux, sea compartido o no, puedes crear un repositorio ahí:

mkdir -p ~/repos/photos-scripts.git
git --bare init ~/repos/photos-scripts.git

De lo contrario, Github es una opción interesante. En mi caso, voy a utilizar dos repositorios: uno público en Github para el código y uno privado para datos sensibles que vamos a suponer están en Fotos/dataa tí te voy a contar dónde están :P

Paso 3. Vincular ambos repositorios.

Git no tiene el concepto de un repositorio central del que se derivan todas las copias locales, como CVS o Subversion. Para Git, todas las copias son repositorios, así que todo son repositorios. Lo que tenemos ahora es un repositorio en la máquina local y un repositorio en un servidor, lo que queremos es vincularlos. Esto se hace añadiendo el remoto al local, así:

git remote add origin ssh://miguev.net/home/miguev/repos/stuff.git

Para el repositorio en Github, es diferente:

git remote add github git@github.com:miguev/photo-scripts.git

Aquí he preferido usar github en lugar de origin por claridad.

Esta operación sólo establece el vínculo entre ambos repositorios, pero no transmite nada entre ellos. Para enviar los contenidos al repositorio remoto, hay que empujarlos:

git push origin master

Para el repositorio en Github, usar github en lugar de origin:

git push github master

Paso 4. Crear una copia local nueva.

O lo que es lo mismo, crear un nuevo repositorio clonando uno que sea accesible:

git clone ssh://miguev.net/home/miguev/repos/stuff.git

Para clonar un repositorio público en Github, lo mismo pero con acceso de sólo lectura:

git clone http://github.com/miguev/photo-scripts.git

A partir de ahí tienes un repositorio completamente funcional en tu propio disco local. Puedes hacer cambios y guardarlos (commit) sin estar conectado a Internet.

Paso 5. Integrar los cambios de vuelta al repositorio remoto.

Tras hacer cambios en los ficheros, añadir ficheros, etc. viene el momento de guardar (commit) esos cambios, de forma que si algo va mal más adelante se puede volver atrás. Esta operación es igual que en CVS y Subversion:

git add muestra.txt
git commit -a -m "Muestra gratuita." muestra.txt

Sin embargo, al contrario que CVS y Subversion, esta operación nunca envía los cambios a un servidor remoto, de modo que el repositorio remoto los recibe. Aquí está la gracia de que Git sea un sistema de control de versiones distribuido: puedes guardar todos los cambios que quieras en tu repositorio sin molestar a nadie ;-)

Una vez que los cambios guardados están listos para publicar (para algún valor de publicar), la operación necesaria es empujar el repositorio local hacia el remoto:

git push origin master

Para el repositorio en Github, usar github en lugar de origin:

git push github master

Paso 6. Recuperar esos cambios de vuelta al repositorio original.

Esta operación no es sino la inversa de la anterior:

git pull origin

Para el repositorio en Github, usar github en lugar de origin:

git pull github

Paso 7. Tener cuidado.

Cuando se hacen cambios en varios repositorios locales, hay que tener quidado de sincronizar cada uno (pull) con el repositorio remoto antes de enviarle a éste los cambios (push) ya que de lo contrario se producen conflictos al intentarlo. En estos casos, Git muestra una ayuda bastante buena que explica todo muy bien :-)

Aunque sea vieja (algo más de 3 años) y posiblemente no viene a cuento, no puedo terminar sin recomendarles la esta introducción a Git, del mismo Linus Torvalds. Tiene algunos golpes muy buenos :-)