Continuamos con la Instalación y uso básico de Git…

GIT

GIT es un sistema de control de versiones distribuido, bastante diferente a SVN o CVS

En local no se almacena únicamente la copia de trabajo con la ultima versión del software si no que tenemos una copia completa del repositorio.

Esto significa que no hay que «ir» al servidor central para las operaciones contra el repositorio, lo cual incrementa enormemente acciones como consultar la historia de un archivo y agiliza todo el proceso con el repositorio. Prácticamente se puede realizar todo el trabajo típico contra un repositorio sin tener que estar conectado al repositorio central.

Además, guarda los datos como snapshots en vez de como diferencias respecto de una versión base

Usando GIT

Hay documentación exhaustiva y muy buena en la web sobre GIT. Solo por citar algún sitio, tenemos

• Manual de referencia: http://git-scm.com/docs
• Libro oficial: http://git-scm.com/book
• Sitio para probar GIT de forma interactiva: http://try.github.com/levels/1/challenges/1 (Para realizar ciertas acciones, nos pide crear una cuenta en GIThub).

Existen varios sitios que nos pueden alojar nuestros repositorios, si no queremos/podemos tener uno propio. Entre los más conocidos están estos dos:

GIThub, que nos permite crear de forma gratuita repositorios únicamente públicos (aunque ilimitados en número y colaboradores)

Bitbucket, que permite repositorios privados ilimitados pero con un máximo de 5 usuarios en su plan gratuito.

Empecemos configurándolo. GIT guarda la configuración en tres niveles:

Usuario

Con la opción –global podemos almacenar valores para el usuario

Usa el archivo ~/.GITconfig

Repositorio

en .GIT/config almacena valores para el repositorio en el que se crea.

Para todos los repositorios

en /etc/GITconfig se guarda la configuración para todos los repositorios, pasando la opción –system

Una de las primeras cosas a configurar es nuestro usuario y el proxy, si estamos detrás de uno.

$ GIT config --global user.name "John Doe" 
$ GIT config --global user.email johndoe@example.com 
$ GIT config --global http.proxy http.proxy=http://usuario:contraseña@nombreProxy: puerto 

O el editor a usar para los comentarios y otros mensajes…

$ GIT config --global core.editor emacs 

O la herramienta para comparar diferencias a la hora de resolver conflictos…

$ GIT config --global merge.tool vimdiff 

Para ver los valores configurados, solo hay que hacer: GIT config –list

Algunas opciones interesantes son estas

user.name=sbgermanm
user.email=sbgermanm@gmail.com
http.proxy=http://usuario:contraseña@nombreProxy: puerto

Para cerrar el artículo, voy a poner algunos comandos básicos, en una secuencia más o menos posible.

En el servidor

En el servidor, creamos un repositorio central creamos un directorio para nuestros proyectos

$ mkdir projects 
$ cd projects/ 

Dentro de él, un directorio para los repositorios que creemos

~/projects$ mkdir repos                                                                                                         
~/projects$ cd repos 

Crearemos un directorio para el primero de esos repositorios

~/projects/repos$ mkdir project.GIT 
~/projects/repos$ cd project.GIT/ 

Ahora creamos un repositorio GIT

~/projects/repos/project.GIT$ GIT init --bare 

En local

Ahora que ya tenemos el repositorio central, creamos una copia local del repositorio (suponiendo que ya está configurado el SSH)

$ GIT clone usuario@servidor:projects/repos/project.GIT  (1)

Como está vacío, nos lanzará una advertencia bastante lógica

warning: You appear to have cloned an empty repository.

También podemos hacer un repositorio vacio (2)

$ GIT init 

Y despues configurar el remoto

$ GIT remote add origin user@server:~/repos/project.GIT/ 

o también

$GIT config remote.origin.url "usuario@servidor:/projects/repos/project.GIT" 

(es posible clonar un repositorio existente como está en (1) o podemos crear uno nuevo en nuestra maquina y configurar el remoto como en (2), es exactamente lo mismo)

Creamos un archivito con cualquier cosa

$ vi readme.txt 

Ahora, vamos a añadir el archivo al indice repositorio local

$ GIT add . 

Si ejecutamos «GIT status» el archivo readme.txt aparecerá como «staged»

Lo siguiente seria subir esos cambios al repositorio local…

$ GIT commit -m "primer archivo" 

Y así podríamos seguir trabajando en local, tanto nosotros como cualquiera que tenga acceso a la ruta donde lo tenemos.

Cuando queramos subir al repositorio «central», haremos lo siguiente

$ GIT push origin master

Creación de ramas y merges

Para crear una nueva rama llamada “experimento»,

$ GIT branch experimento 

Para obtener la lista de todas las ramas existentes

$ GIT branch 

experimento

* master

El asterisco marca nuestra rama actual.

Para cambiarnos a la rama experimento:

$ GIT checkout experimento

[Editamos el archivo y lo subirlo]

$ GIT commit -a 

Volvemos a la rama principal.

$ GIT checkout master 

[Editamos el archivo]

$ GIT commit -a 
$ GIT merge experimental 

Si no hay conflictos en los cambio, ya está. En caso contrario podremos ver las diferencias:

$ GIT diff 

Si hay conflictos, se mostrará marcas en la izquierda de las líneas problemáticas y GIT commit no funcionaria, diría algo como  esto: file.txt: needs merge

$GIT status

Con GIT status podemos listar los archivos no mergeados. Los archivox con conflictos tendrán algo como esto:

<<<<<<< HEAD:file.txt
Hello world
=======
Goodbye
>>>>>>> 77976da35a11db4580b80ae27e8d65caf5208086:file.txt

Solo tenemos que editar los archivos para resolver los conflictos y entonces:

$ GIT add file.txt 
$ GIT commit 

Ahora subimos el resultado del merge

$GIT commit -a 

Una vez finalizado el trabajo en la rama “experimento”, podemos borrarla:

$ GIT branch -d experimento

Si ni siquiera queremos mergear la rama y solo queremos borrarla

$ GIT branch -D prueba_basura 

Y esto es todo. Ha quedado un poco extenso, pero creo que son las instrucciones mínimas para lanzar desde cero nuestro propio repositorio.

Recientemente hemos instalado GIT en nuestro hosting para empezar a controlar las versiones de nuestro software de forma más eficiente.

Aunque ya había usado GIT desde Github y bitbucket, no lo había instalado nunca en un servidor y me dije, «esta es la mía…».

De paso, aprovecho para escribir estas líneas, recapitular lo que he hecho y añadir unas líneas muy, muy básicas del uso de GIT. Empecemos….

Pasos previos

Cliente Local

Lógicamente, para poder acceder a los comandos de GIT, tenemos que tener instalado en local GIT, El sitio oficial de GIT es http://git-scm.com/. Para instalar el cliente de Windows, redirige a  http://msysgit.github.com/.

En el caso de instalar el cliente en Windows, tenemos un plus adicional, nos pregunta si quieremos instalar diversos comandos típicos de Linux, lo cual es muy útil, así como una shell bash para Windows, git_bash. En este artículo usaré algunos de ellos, por comodidad.

Acceso por SSH.

Aunque GIT se puede usar con otros protocolos, el más conveniente es SSH. Nos permitirá limitar el acceso al repositorio a solo aquellas personas cuyas claves publicas hayamos instalado en el servidor, sin necesidad de crear usuarios específicos en nuestro servidor.

Vamos a empezar por ver el proceso de creación de las claves SSH.

No me propongo explicar cómo funciona el tema de las claves publicas porque queda fuera del alcance artículo, pero si alguien lo necesita, por aquí cuentan algo: http://git-scm.com/book/en/Git-on-the-Server-Generating-Your-SSH-Public-Key

Es necesario saber que en Ubuntu se usa openssh, con lo que las claves no son compatibles claves SSH como las generadas desde Putty… pero podemos convertirlas…. Tenemos varias posibilidades para usar SSH correctamente, pero la mejor es la última reseñada.

1. Podemos generar las claves en ubuntu:

DESDE UBUNTU

1. Generar las claves openssh en Ubuntu, ejecutar ssh-keygen para generar una par de claves.
2. Meter la clave en el almacén: cat clave.publica >> ~/.ssh/authorized_keys
3. Copiar la clave privada al Windows:

scp GIT@123.123.123.123:/home/GIT/kk/clave.privada c:windowstemp

DESDE WINDOWS

Como hemos dicho antes, putty necesita claves de tipo SSH no openSSH. Para convertir la clave generada en Ubuntu,

ejecutar puttygen

hacer un «load» de la clave privada que hemos copiado en Windows.

Al hacerlo, puttygen lo reconoce como openssh y la importa. Tenemos que guardarla (como SSH) para usarla desde el putty

A partir de aquí, ya podemos usar putty dándole la clave privada ssh

2. Otra posibilidad es generarla desde Windows

Podemos generar claves SSH con puttygen

Si generamos con puttygen y guardamos las claves, las guarda como SSH pero muestra la clave pública en formato openSSH en la propia ventana:

Podemos copiar esta clave pública y ponerla en el fichero ~/.ssh/authorized_keys

También es posible subir la clave pública (o privada) generada desde Windows y convertirla y almacenarla en Ubuntu de esta forma:

ssh-keygen -i -f clave.pub >>.ssh/authorized_keys

3. La mejor opción es usar el ssh-keygen que trae el cliente para Windows de http://msysGIT.GIThub.com/,:

Arrancar GIT_bash
Generar clave:  ssh-keygen -t rsa -C «pepito@sevidor.com»

Importante para Windows: este comando crea las claves en %USERPROFILE%/.ssh

Importante: el nombre del archivo de clave (privada) tiene que ser id_rsa.

1. Esto nos habrá generado un par de claves openSSH
2. Lo siguiente será subir la clave publica al servidor y, en el caso de Linux, añadirla  en ~/.ssh/authorized_keys: cat id_rsa.pub >> ~/.ssh/authorized_keys
3. Si además queremos usarla desde putty, tenemos que convertir la clave privada al formato de putty:
   1. Entrar en puttygen
   2. En el menu, conversions, import key
   3. Elegimos nuestro id_rsa
   4. Damos a «save private key» y le damos un nombre
   5. Este es el que debemos usar desde putty.

Instalación de GIT en UBUNTU

Para instalar GIT tenemos dos posibilidades:

1. Usar un PPA(<http://www.makeuseof.com/tag/ubuntu-ppa-technology-explained/> )
2. Ir por los repositorios oficiales

1. PPA

Una forma de actualizar/obtener el software en Ubuntu es a través de los repositorios oficiales. Estos son actualizados cada 6 meses, que es cuando se libera una nueva versión del sistema operativo. Actualizar a través del repositorio oficial es muy cómodo, evita tener que ir buscando el software a cada uno de los proveedores y además, pasa el filtro oficial del equipo de Ubuntu. Pero claro, cada 6 meses.

Si tu software favorito ha sido actualizado, tienes que esperar a la liberación semestral para instalarlo desde el Ubuntu Software Center. A no ser que uses un PPA, un Personal Package Archives, que es la forma de acceder rápidamente a la última versión publicada.

Un PPA suele centrarse en un único paquete de software. Te permite, por ejemplo, instalar software que aun no ha sido liberado.

Para usarlo, lo primero que se hace es añadir el repositorio del programa al «sources.list». De esta forma obtendremos el programa y además, obtendremos las futuras actualizaciones, de la misma forma que el resto del software.

Por lo tanto los pasos para añadir la última versión de GIT serian los siguientes:

1. Añadimos el repositorio

sudo add-apt-repository ppa:git-core/ppa

1. Hacemos un update de APT

sudo apt-get update

1. instalamos el paquete GIT-core:

sudo apt-get install git-core

Y ya está. Mucho más fácil de hacer que de explicar.

 

2. Repositorio por defecto

Simplemente tenemos que hacer lo siguiente:

sudo apt-get install git-core

Crear un usuario con acceso SSH dedicado para GIT

Crear el usuario, por ejemplo “GIT”

sudo adduser git

Ahora necesitamos que los desarrolladores que vayan a usarlo nos pasen sus claves públicas para añadirlas al ssh.

Tienen esta forma

cat /tmp/id_rsa.pepe.pub

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCB007n/ww+ouN4gSLKssMxXnBOvf9LGt4LojG6rs6hPB09j9R/T17/x4lhJA0F3FR1rP6kYBRsWj2aThGw6HXLm9/5zytK6Ztg3RPKK+4kYjh6541NYsnEAZuXz0jTTyAUfrtU3Z5E003C4oxOj6H0rfIF1kKI9MAQLMdpGW1GYEIgS9EzSdfd8AcCIicTDWbqLAcU4UpkaX8KyGlLwsNuuGztobF8m72ALC/nLF6JLtPofwFBlgc+myivO7TCUSBdLQlgMVOFq1I2uPWQOkOWQAHukEOmfjy2jctxSDBQ220ymjaNsHT4kgtZg2AYYgPq dAv8JggJICUvax2T9va5 gsg-keypair

Tenemos que añadir todas al fichero .ssh/authorized_keys

$ cat /tmp/id_rsa.pepe.pub >> ~/.ssh/authorized_keys
$ cat /tmp/id_rsa.maria.pub >> ~/.ssh/authorized_keys
$ cat /tmp/id_rsa.javineitor.pub >> ~/.ssh/authorized_keys

 

Ya tenemos todo listo, ahora ya podemos crear el repositorio

1. cd $someWhere
2. mkdir repositoriosGIT
3. cd !$
4. mkdir proyecto1.GIT
5. cd !$
6. git –bare init

A partir de aquí, cada desarrollador tendrá que «bajarse» el repositorio.

Pero, como esto se está alargando, lo veremos en una segunda entrada…