git, el control de versiones definitivo (por ahora)

Una pequeña introducción a git, el sistema de control de versiones de moda.

Ingredientes

• git-core – fast, scalable, distributed revision control system

Identidad del usuario

Para las operaciones de log, git necesita una identificación del usuario, para ello usa estos dos comandos:

$ git config [--global] user.email "juan.nadie@babia.es"
$ git config [--global] user.name "Juan Nadie"

Creando un repositorio

Partiendo de un directorio (sea nuevo o no):

juan@example:~/iexplorer9$ git init
Initialized empty Git repository in .git/

Añadir contenido

Lo primero es añadir el propio directorio donde has inicializado el repositorio:

juan@example:~/iexplorer9$ git add .

Y después, del mismo modo puedes añadir cualquier fichero que crees en ese directorio o en los que contiene.

Commit

Como en la mayoría de los VCS (Version Control System) para hacer que los cambios sean permanentes y se cree una nueva versión es necesario ejecutar un “commit”. La sintaxis en git es obvia:

juan@example:~/iexplorer9$ git commit

Y como también es habitual, pide un mensajito para informar al prójimo del propósito de los cambios realizados. Y aquí viene “la pregunta”: ¿dónde han ido esos cambios si no has indicado en ningún momento el servidor? Pues esa es una diferencia fundamental con CVS o Subversion, no tiene porqué haber un servidor que mantenga el repositorio, CVS y Subversion eran centralizados, git es distribuido.

En resumen, todo lo anterior es para crear y mantener un repositorio personal individual.

Descargar una copia del repo

Evidentemente git tendría poco interés si no diera la posibilidad de que varias personas trabajaran sobre el mismo repositorio. Otro usuario “pepe” que tenga cuenta en la misma máquina puede obtener una copia del repo de juan con:

pepe@example:~$ git clone /home/juan/iexplorer9 micopia

Trabajo en equipo

Pepe puede ahora hacer cambios sobre su copia del repo. El usuario Juan puede integrar esos cambios en su repo con:

juan@example:~/iexplorer9$ git pull /home/pepe/micopia

Si Juan va a realizar esta operación frecuentemente y además quiere tener un control más fino de los cambios puede utilizar un mecanismo alternativo:

juan@example:~/iexplorer9$ git remote add pepe /home/pepe/micopia
juan@example:~/iexplorer9$ git fetch pepe

A diferencia de pull, el comando fetch crea una rama, que se puede mezclar con la rama principal:

juan@example:~/iexplorer9$ git merge pepe/master

o lo que es lo mismo:

juan@example:~/iexplorer9$ git pull . remotes/pepe/master

Modo “centralizado”

En el apartado anterior, los cambios se piden siempre explícitamente. Hay otra alternativa: el comando push que permite trabajar de una forma similar a la que se utiliza CVS o Subversion. En ese caso, Pepe puede enviar sus cambios a la copia de Juan con:

pepe@example:~/micopia$ git push

Y puede actualizar su copia con:

pepe@example:~/micopia$ git pull

Acceso remoto

Es posible obtener una copia desde otra máquina mediante SSH:

manolo@box:~$ git clone ssh://example.org/~juan/iexplorer9

También es posible acceder remotamente con WebDAV y rsync

Referencias

• A tutorial introduction to git
• Everyday GIT With 20 Commands Or So
• Git – SVN Crash Course
• git for CVS users