Ene 172013
 

En nuestro anterior artículo de introducción al sistema de control de versiones git, hemos comentado ya que una de las principales diferencias entre git y otros sistemas como subversion, es que no existe un repositorio centralizado. En su lugar, cada desarrollador trabaja con un repositorio local completo en su propio ordenador, y se conecta a los repositorios remotos de los otros desarrolladores para obtener las nuevas versiones de cada uno de los elementos que componen los proyectos en los que trabaja.

En este artículo vamos a explicar en detalle cómo se produce esta comunicación entre repositorios.

Preparar el repositorio para que sea accesible desde otros ordenadores.

Como ya hemos visto en el anterior artículo, el repositorio git local se encuentra bajo el directorio “.git” en la raíz de la copia de trabajo del proyecto. Para hacerlo accesible al resto de los desarrolladores, debemos exportarlo a un nuevo repositorio “proyecto.git” que no incluye una copia de trabajo (un “bare” repository). Esto se hace pasandole la opción “–bare” al comando “git clone”. Ejemplo:

$ git clone --bare mi_proyecto mi_proyecto.git
Cloning into bare repository 'mi_proyecto.git'...
done.

 

El resultado de este comando es casi idéntico (con algunas diferencias en el fichero de configuración) al de copiar el repositorio con el comando:

$ cp -Rf mi_proyecto/.git mi_proyecto.git

A continuación, copiamos el nuevo repositorio a un servidor al que los demas desarrolladores tengan acceso ssh:

Suponiendo que el servidor se llama git.ejemplo.com y que los repositorios se van a guardar bajo el directorio /opt/git podemos hacer la copia con un comando “scp” de la forma:

$ scp -r mi_proyecto.git usuario@git.ejemplo.com:/opt/git

Con esto, cada uno de los demás desarrolladores puede hacer una copia local del repositorio con el comando “git clone”:

$ git clone usuario@git.ejemplo.com:/opt/git/mi_proyecto.git

Preparar un repositorio centralizado

En git también es posible tener un repositorio centralizado, y que un grupo de desarrolladores trabaje de manera similar a como se hace en subversion.

Para ello, después de haberse conectado al servidor “gitserver” por ssh, comenzamos creando un usuario “git”:

$ sudo adduser git
$ su git
$ cd
$ mkdir .ssh

Bajo el directorio “.ssh”, creamos el fichero “authorized_keys”, y añadimos al mismo las claves públicas de los desarrolladores que tendrán acceso al repositorio:

$ cat /tmp/id_rsa.john.pub >> ~/.ssh/authorized_keys
$ cat /tmp/id_rsa.josie.pub >> ~/.ssh/authorized_keys
$ cat /tmp/id_rsa.jessica.pub >> ~/.ssh/authorized_keys

A continuación, creamos un repositorio totalmente vacío, y sin copia de trabajo, en “/opt/git”:

$ cd /opt/git
$ mkdir proyecto.git
$ cd proyecto.git
$ git --bare init

A continuación, uno de los usuarios puede enviar una copia inicial del proyecto al servidor:

# on Johns computer
$ cd mi_proyecto
$ git init
$ git add .
$ git commit -m 'initial commit'
$ git remote add origin git@gitserver:/opt/git/proyecto.git
$ git push origin master

y los demás pueden obtener una copia clonando el repositorio del servidor, trabajar con ella y actualizar el servidor:

$ git clone git@gitserver:/opt/git/proyecto.git
      (Esto crea el directorio "proyecto" y copia en él los ficheros) 
$ cd proyecto
      (Editamos uno de los ficheros del proyecto)
$ vim README
      (Guardamos la nueva versión en el repositorio local)
$ git commit -am 'nueva versión del fichero README'
      (Enviamos la nueva versión al repositorio centralizado)
$ git push origin master

 Publicado por en 6:28 pm

 Deja un comentario

(requerido)

(requerido)