Dic 012012
 

Después de muchos años durante los cuales el sistema de control de versiones subversion (svn) ha sido el más ampliamente utilizado en el desarrollo de software, y especialmente en el software open source, ha aparecido git, que se está implantando rápidamente como el sucesor de svn.

En este artículo recogemos algunos apuntes sobre las características de git y las diferencias entre éste y subversion, así como los primeros pasos a dar para trabajar con git en un servidor linux debian.

Diferencias entre svn y git

Para un desarrollador acostumbrado a trabajar con subversion, git presenta dos importantes diferencias

Por una parte, en svn existe un repositorio central. cada desarrollador utiliza a una copia de trabajo. Cuando ha realizado cambios en los ficheros de la copia de trabajo, los guarda en el repositorio central:

Por el contrario, git es un sistema distribuido, en donde cada desarrollador tiene un repositorio completo. Cada desarrollador tiene la posibilidad de incorporar a su repositorio local los cambios en los repositorios de otros desarrolladores. Estos son repositorios “remotos” desde el punto de vista del primero.

Además, entre el área de trabajo y el repositorio de cada desarrollador, existe un área intermedia conocida como “index”, “cache” o “staging area”. Los ficheros modificados se copian primero al area intermedia o “index”, y despues se copian desde el “index” al repositorio local:

Instalación de git y configuración inicial

Comenzamos por instalar git. En Debian, simplemente instalamos con “apt-get” el paquete “git”:

A continuación, configuramos nuestro nombre completo y dirección de correo. Estos datos quedan grabados en el fichero $HOME/.gitconfig, y son los valores que se aplicarán por defecto a todos los repositorios que creemos:

La configuración global queda guardada en un fichero ~/.gitconfig en el directorio de login del usuario.

Creación de un nuevo repositorio git

Creamos un directorio para contener el repositorio, y en él ejecutamos el comando “git init”:

Con esto, se crea un único subdirectorio “.git” para almacenar la información de control del nuevo repositorio. Esta es una primera diferencia entre git y subversion, porque en subversion se crea un subdirectorio “.svn” debajo de cada uno de los subdirectorios del repositorio.

Obtener ayuda sobre los comandos git

Con el comando “git help” obtenemos una lista de los comandos más comunes para manejar el repositorio:

Además, podemos acceder a la página de manual correspondiente a cada comando para obtener ayuda más detallada sobre el mismo mediante:

o bien

Guardar ficheros en el repositorio – Primera fase: “staging”

En git, los ficheros se envían al repositorio en dos fases, llamadas “staging” y “commit”.

En la primera fase, llamada “staging”, el contenido de los ficheros se copia a  un área intermedia, llamada “index” o “cache”, con el comando “git add <fichero>”. La operación contraria, para eliminar ficheros del area intermedia se realiza con el comando “git rm <fichero>”.

Después de copiar un fichero al área intermedia, podemos seguir modificandolo, pero cuando guardemos definitivamente los ficheros en el repositorio, lo que se guarda es la copia, y no el contenido actual del fichero en el directorio de trabajo.

Primero creamos unos ficheros de prueba:

Y a continuación los copiamos al área intermedia:

En cualquier momento, podemos comprobar el estado del repositorio con el comando “git status”:

Si a continuación modificamos uno de los ficheros, podemos ver que “git status” indica esta modificación, y advierte de que los últimos cambios realizados al fichero desde que se guardó en cache no serán guardados en el repositorio, hasta que no se vuelvan a guardar en cache con el comando “git add”:

Como hemos señalado más arriba, el comando “git rm <fichero>” revierte los cambios efectuados por “git add <fichero”.

 

Guardar ficheros en el repositorio – Segunda fase: “commit”

En la segunda fase, el contenido copiado en cache es guardado en el repositorio con el comando “commit”. Igual que en subversion, este comando admite el flag “-m” para añadir un mensaje descriptivo de los cambios realizados:

Ahora podemos comprobar el nuevo estado del repositorio:

y también ver el cambio en el registro de cambios, con el comando “git log”:

Commit directo

Si un fichero que ya estaba copiado en cache ha sido modificado directamente, podemos guardarlo directamente en el repositorio sin necesidad de ejecutar nuevamente el comando “git add”:

También podemos copiar automáticamente en cache todos los ficheros modificados y guardarlos en el repositorio con el comando “git commit -a”:

Guardar ficheros en el repositorio – Resumen

o bien:

Revisar los cambios realizados

La revisión de cambios se realiza con el comando “git diff”. Pero como un mismo fichero puede tener distintas modificaciones en el área de trabajo, en el área intermedia y en el repositorio, hay tres posibilidades de comparación:

  • Comparar el fichero en el área de trabajo con el fichero en el área intermedia:

  • Comparar el fichero en el área de trabajo con el fichero en el repositorio:

  • Comparar el fichero en el área intermedia con el fichero en el repositorio:

también se puede utilizar el switch “–staged” como sinónimo de “–cached”:

Deshacer los cambios realizados

También en este caso tenemos varias posibilidades:

  • Deshacer los cambios en el área de trabajo y en el área intermedia, recuperando el contenido del repositorio:

  • Deshacer los cambios en el área de trabajo, recuperando el contenido del área intermedia

  • Recuperar en el área intermedia el contenido del repositorio (no se modifica el área de trabajo):

Recuperar en el área de trabajo una versión anterior del fichero

En el punto anterior hemos visto que utilizamos la palabra clave HEAD, que es un sinónimo de “la versión más reciente en el repositorio”. Para recuperar otras versiones, sustituimos HEAD por el identificador de la versión deseada:

$ git checkout <commit> <fichero>

El identificador es una cadena hexadecimal de cuarenta bytes, que podemos obtener con el comando “git log”. Por ejemplo:

Como vemos, hay dos versiones guardadas de “fichero_uno.txt”. la más reciente tiene el identificador de versión “42b1de7ef387d30bab3b0849c229d6006c02f2e1”, y la anterior tiene el identificador “a36dc32d4d5f6428ddc14fb91c5858548ba79669”.

Si queremos recuperar la primera versión del fichero, debemos ejecutar el comando:

En el próximo artículo de esta serie veremos la manera de trabajar con repositorios remotos en git.

 

 Publicado por en 1:11 pm

 Deja un comentario

(requerido)

(requerido)