Al terminar este tutorial tendremos un entorno de trabajo basado en Git, pudiendo desarrollar en nuestro PC de escritorio, y enviando los cambios a un repositorio central en un servidor remoto. El único requisito es tener instalado y configurado SSH en el servidor remoto, y tener un usuario que pueda conectar a él por este protocolo.

Instalación

Nada más sencillo: basta con instalar el paquete git-core con sus dependencias. En caso de preferir compilarlo, o si tu distribución no lo tiene en respositorios, debemos bajarlo de http://git-scm.com/download y asegurarnos de tener las librerías de desarrollo de curl, zlib, openssl, expat, y libiconv instaladas. La compilación es la clásica.

Windows y Mac

Si eres usuario de Windows tendrás que usar un paquete que incluye una sencilla línea de comandos, git y un cliente SSH: Msysgit. Basta con descargarlo de http://code.google.com/p/msysgit y ejecutar el instalador.

En Mac se puede instalar con el instalador gráfico que ofrece Git, que se puede bajar de http://code.google.com/p/git-osx-installer, o bien usando MacPorts:

$ sudo port install git-core +svn +doc +bash_completion +gitweb

Infraestructura

Yo suelo trabajar de la siguiente manera: tengo un equipo de desarrollo, que a su vez hace de servidor local de pruebas (con un sencillo script arranco o paro los servidores, pasando así de PC de escritorio a servidor y viceversa). El desarrollo lo hago sobre este equipo. Tengo otro servidor de pruebas, que es un VPS alojado en OVH; en este servidor tengo el repositorio de código y la web de pruebas. El repositorio está aquí para tenerlo disponible en otros ordenadores (portátil cuando salgo de viaje) y, ocasionalmente, para otras personas con las que colaboro; podría tenerlo en mi PC de casa, el de desarrollo, pero eso me obligaría a tener un DynDNS o similar para apuntar a mi IP dinámica, abrir el puerto del router, etc. El esquema sería:

Configurar el entorno de trabajo

Inicializar el proyecto

En el PC local, de desarrollo, inicializaré un directorio que será donde esté el directorio de trabajo de Git, y sobre el que programaré el proyecto. Con Git todo es muy sencillo:

$ cd nuevo-proyecto
$ git init
Initialized empty directory in /home/usuario/Proyectos/nuevo-proyecto

Una vez inicializado hay que añadir todos los archivos que ya tuviéramos en el directorio del proyecto. Para ello se utiliza el comando add. add añade los archivos al directorio de trabajo de Git y los marca para enviar.

$ git add *

Ya sólo nos quedaría hacer el primer commit para tener el proyecto listo para usar el control de versiones de Git. El comando commit requiere una descripción del cambio que estamos enviando, que se da directamente con el parámetro –m; si no se pasa este parámetro Git abrirá el editor por defecto del sistema para que escribamos esta descripción:

$ git commit -m "Inicialización de nuevo-proyecto"
Created initial commit 848af8e: Inicialización de nuevo proyecto
0 files changed, 0 insertions(+), 0 deletions (-)

Subir repositorio al servidor

Como queremos tener el repositorio central en un servidor externo, de forma que pueda ser accesible desde otros ordenadores o por otras personas, vamos a crear un repositorio y a subirlo. Esta copia será sólo del repositorio, pero no incluirá el directorio de trabajo (opción --bare), es decir, en el repositorio del servidor no habrá archivos en sí, sino sólo lo que es el repositorio de cambios del proyecto.

$ git clone --bare nuevo-proyecto nuevo-proyecto.git
Initialize nuevo-proyecto.git
Initialized empty directory in /home/usuario/Proyectos/nuevo-proyecto.git
$ scp –r nuevo-proyecto.git usuario@miservidor:/var/git

En mi servidor tengo ese directorio /var/git, que es donde residen todos los repositorios en activo, y un usuario con acceso SSH y permisos para escribir en este directorio. Cualquier usuario con permisos de escritura en /var/git/nuevo-proyecto.git podrá enviar código al repositorio;  si se usa la opción --shared, Git dará permisos de escritura al grupo en el repositorio. Para dar acceso a descarga anónima (por ejemplo, para betatesters o para usuarios si se trata de software libre) basta con crear un usuario genérico en el servidor, con acceso por SSH pero sin poder hacer login, y con permisos sólo de lectura en el directorio del repositorio central, aunque si planeamos un desarrollo muy distribuido como software libre es preferible usar el protocolo git://.

Añadir repositorio remoto a PC local

Para poder comunicarnos con este nuevo repositorio central remoto, debemos añadirlo como origen remoto a nuestro directorio de desarrollo. Esto, así como toda la comunicación en remoto, se puede hacer por varios métodos (SSH, protocolo git://, etc.) pero en todo momento usaré SSH por ser el más sencillo de implementar y mantener para pequeños equipos de trabajo (¡casi siempre soy yo solo!).

$ git remote add origin ssh://usuario@miservidor/var/git/nuevo-proyecto.git

El parámetro origin es opcional, es el nombre con el que referenciaremos este repositorio remoto, si no se da por defecto Git llamará origin al repositorio remoto. Si sólo vamos a usar un repositorio remoto, podríamos obviar este parámetro. Se le podría haber dado otro nombre de referencia (por ejemplo npdev de nuevo-proyecto development) así:

$ git remote add npdev ssh://usuario@miservidor/var/git/nuevo-proyecto.git
usuario@miservidor’s password:

Pide la contraseña del usuario que conecta por SSH.

Se pueden ver los repositories remotos asociados con:

$ git remote -v
origin usuario@miservidor:/var/git/nuevo-proyecto.git

O podemos obtener toda la información de un repositorio remoto, por ejemplo, el llamado origin, con:

$ git remote show origin

Añadir directorio de desarrollo en servidor

Quiero disponer de un directorio en mi servidor donde pueda hacer pruebas antes del paso a producción, por lo que debemos clonar el repositorio central en otro directorio del servidor, para tener un directorio de trabajo al que apuntar Apache.

$ git clone /var/git/nuevo-proyecto.git
Initialized empty directory in /var/www/vhosts/nuevo-proyecto

Flujo de trabajo

Ya tenemos lista toda la infraestructura. Ahora, en el flujo de trabajo normal, trabajaremos sobre el código en el PC de escritorio. Cuando tengamos algún cambio que queramos guardar, hacemos add y commit y seguimos trabajando; al hacer add se añaden los archivos que han cambiado al directorio de trabajo de Git, para ser enviados en el próximo commit, ya que si no hacemos el add, commit nos informará de que esos archivos tienen cambios pero no están en el directorio de trabajo. Si hacer ambos pasos nos aburre, commit nos ofrece una opción para hacer todo en uno:

$ git add *
$ git commit -m “Mensaje de este envío”

O bien

$ git commit –a –m “Mensaje de este envío”

Cuando queramos enviar los cambios al repositorio central basta con hacer push. push funciona sobre diversos protocolos, pero como ya comenté anteriormente, yo utilizo SSH por ser el más sencillo y por tenerlo ya configurado para acceso remoto al servidor. Simplemente hay que lanzar el push con un usuario con permisos para conectar por SSH y escribir en el directorio del repositorio central:

$ git push
usuario@miservidor’s password:

Si estamos utilizando varios servidores remotos, o tenemos varias ramas de desarrollo, es obligatorio especificarlas en ese orden, por ejemplo, para el servidor remoto referenciado como origin, y para la rama master (estos son los valores por defecto):

$ git push origin master

Cuando queramos probar en el servidor los nuevos cambios, debemos actualizar el repositorio al que apunta Apache para reflejar los cambios. Hacemos esto con pull desde el directorio de desarrollo del servidor (en el ejemplo, /var/www/vhosts/nuevo-proyecto):

$ git pull

Si hay más desarrolladores en el equipo, todos estarán dejando sus cambios en el repositorio central, por lo que para trabajar con sus cambios debemos mantener actualizada nuestra copia de trabajo. Para ello se emplea fetch junto al nombre de referencia, en nuestro PC local de desarrollo:

$ git fetch origin

Sin embargo, fetch lo único que hace es descargar los cambios a nuestro directorio de trabajo, pero no los une a tu trabajo actual, esto deberá hacerse posteriormente de forma manual (add y commit). Para mayor comodidad, podemos hacer ambos pasos en uno, bajar cambios y unirlos al trabajo actual:

$ git pull

Conclusión

Con estos pasos ya tenemos configurado el entorno de trabajo con Git como control de versiones. Nos beneficiaremos de la comodidad de uso de Git y de la facilidad de gestionar usuarios (usando SSH es trivial), teniendo un entorno cómodo y adecuado tanto para un solo desarrollador como para un equipo de desarrolladores remotos.

Git da mucho más de sí, permitiendo manejar diversos repositorios y ramas de desarrollo con una gran flexibilidad. Para entrar en más detalle en estos y otros temas se puede leer el libro online Pro Git en http://progit.org/book/ (o comprándolo en formato árbol muerto).