Para este curso asumimos que el lector tiene un entendimiento básico sobre el manejo del terminal en Sistemas Operativos *nix, que sabe y a generado unas llaves de ssh con anterioridad.
Protocolos
Cuando nos referimos a protocolos, hablamos de las reglas y normas que permiten que dos o más entidades se comuniquen entre ellas para transmitir información. Git trabaja con múltiples protocolos de comunicación. Si hacemos referencia a Github ya se habrán dado cuenta que al querer clonar un repositorio existen dos (2) protocolos disponibles, HTTP y SSH. Vamos a explicar cuales son los “pro” y “contras” de ambos, pero para el ejemplo nos basaremos únicamente en ssh.
SSH
Posiblemente SSH sea el medio de transporte de comunicación más utilizado en git. La razón de esto es que en la mayoría de los servidores ya se encuentra instalado por defecto. Por otra parte SSH también es un protocolo de autenticación de red, lo que nos ayuda a filtrar los usuarios que tienen permiso de lectura y escritura en nuestro repositorio.
Pro
- Siempre se debe usar para autenticar escritura en un repositorio.
- Fácil de instalar.
- Se encuentra instalado en casi todos los sistemas *nix.
- El acceso mediante el protocolo es seguro.
- Efectivo a la hora de transferir data.
Contra
- No permite acceso anónimo al repositorio.
- Se debe tener acceso al servidor para poder utilizarlo.
HTTP/S
Este protocolo es el protocolo del internet, y por ende es “muy fácil” de poner a trabajar en cualquier servidor. Para poder utilizar el protocolo con un repositorio es cuestión de crear una carpeta con el repositorio git dentro de una de las carpetas alto tipo /var/www/htdocs/
conocidas por nuestro servidor web (nginx, lighttpd, apache, etc.), activar el post-update
hook que viene dentro de la carpeta hooks y ya.
Pro
- Muy fácil de instalar.
- Todo el mundo tiene acceso de descarga.
- Emplea bajos recursos del servidor.
- Se pueden tener repositorios de solo lectura.
- Por lo general este protocolo siempre se encuentra habilitado detrás de los firewalls.
Contra
- Más lento para clonar y descargar.
- Se transfiere toda la data de repositorio y no los cambios únicamente.
- Es un protocolo “bruto”.
¿Cómo se instala?
Para realizar toda la instalación vamos a utilizar un Sistema Operativo Ubuntu 13.04 de 64 bits. Aparte debemos tener instalado el paquete git-core y además debemos tener creado o saber crear el par de llaves de ssh. De ser posible para facilitar un poco la cosa instalar ssh-copy-id
en la máquina personal.
Lo primero es tener acceso al servidor. Una vez dentro de servidor vamos a crear un usuario llamado git
. Luego copiar la llave ssh del usuario, crear un repositorio y por último subirle contenido al mismo.
1 $sudo adduser git
Seguimos las preguntas e indicaciones para crear el usuario, luego nos cambiamos a ese usuario y creamos la carpeta .ssh
123 $su git$cd$mkdirssh
Ahora existen dos maneras posibles de copiar las llaves del usuario hacia el servidor. Estando en nuestro computador y si tenemos ssh-copy-id
empleamos el siguiente comando.
1 $ssh-copy-id git@192.168.1.2# IP del servidor.
Sino tenemos ssh-copy-id
instalado debemos hacerlo “manual”
1 $catssh/id_rsapub|ssh git@192.168.1.2"cat >> ~/.ssh/authorized_keys"
Les recuerdo nuevamente las llaves ssh deben estar creadas previamente.
Ahora crearemos un repositorio vacío dentro de la carpeta ~/miproyecto
en el $HOME
del usuario.
12345 $mkdir~/miproyecto$cd~/miproyecto$mkdir miproyectogit$cd miproyectogit$git--bare init
La bandera
--bare
genera el repositorio pero completamente vacío.
Ahora en la computadora del usuario o nuestra computadora vamos a subir un proyecto que tengamos a el servidor.
$ cd miproyecto_local $ git init $ git add . $ git commit -m 'initial commit' $ git remote add origin [email protected]:/home/git/miproyecto.git $ git push origin master123456 $cd miproyecto_local$git init$git add$git commit-m'initial commit'$git remote add origin git@192.168.1.2:/home/git/miproyectogit$git push origin master
Listo, a partir de este momento otros “pueden” clonar y subir cambios al proyecto simplemente agregando su llave de ssh al servidor.
¿Fácil cierto? Ya sabemos que es sencillo, pero es un dolor de cabeza estar agregando las llaves ssh de todos los compañeros del proyecto uno a uno, para esto se crearon herramientas como Gitolite y Gitosis. Este par de herramientas son “scripts” que ayudan a manejar las llaves ssh dentro del archivo authored_keys
y a su vez un control de acceso. Instalarlas no es tarea fácil es alto tedioso y por la “complejidad” no lo haremos en este curso, pero queremos que estén al tanto de que estas herramientas existen.
Si llegan a instalar acceso mediante HTTP/S para el repositorio también pueden utilizar un visualizador web del proyecto, es decir, una página web como si fuese Github que les permite ver “commits”, “tags”, “branches” y toda la información relevante del proyecto en una página web súper sencilla pero muy útil. La interfaz se llama GitWeb, para activarla necesitamos un servidor web (valga la redundancia), algo como webrick
en ruby o cualquier otro servidor web sencillo. Se utiliza ejecutando el siguiente comando:
12 $git instaweb--httpd=webrick$git instaweb--httpd=webrick--stop# Para detener el daemon
Recuerden que para que la interfaz sea pública la debemos agregar a un VirtualHost en apache o a un Server Block en nginx.
La información de este artículo fue extraída de el libro Pro Git.
Conclusión
En este último capítulo y en conjunto con los capítulos anteriores hemos adquirido el conocimiento necesario para poder hospedar nuestro propio servidor de git con acceso SSH para nuestro pequeño grupo de trabajo. Te invitamos a revisar la documentación de Git para que extiendas tú conocimiento aún más. Si te surge algún tipo de duda no te detengas y déjanos un comentario, que gustosamente lo responderemos.
¡Esperamos que ésta serie sobre git les haya gustado bastante! Si requieren algún tema adicional que sea de su agrado y no se nombró durante los 16 capítulos de la serie pueden solicitarlo en los comentarios.
¡Saludos!