RSS

Arquitectura de Git

24 Ago

git-logo

Como indicábamos en Git como herramienta de control de versiones , en este post vamos a explicar más detalladamente los principios básicos en los que se sustenta la arquitectura de Git. Las principales características que definen Git respecto otros sistemas de control de versiones son:

  • Snapshots
  • Sistema distribuido de versionado
  • Doble proceso de commit
  • Identificador de commit

Snapshots

En otros sistemas de versionado clásico como pueden ser CVS ó Subversion los cambios tienen la implicación de que se han realizado modificaciones sobre un conjunto de ficheros del proyecto versionado. Sin embargo, Git funciona bajo el sistema de Snapshots, es decir, cuando queremos versionar nuestro proyecto lo que hacemos es realizar una foto en ese determinado instante sobre nuestro proyecto. Los siguientes esquemas ilustran la diferencia entre un sistema clásico de versionado frente a Git.

Sistema de versionado basado en cambios en los ficheros

Sistema de versionado basado en cambios en los ficheros

Snapshots de Git

Snapshots de Git

El hecho de que Git se base en esta definición de Snapshots le confiere una gran flexibilidad y potencia. Al recuperar una determinada Snapshot podemos regresar al estado exacto de cómo estaba nuestro proyecto en un determinado instante.

Sistema distribuido de versionado

¿Cuál es el sistema tradicional de versionado?. Simple, una serie de desarrolladores comparten un repositorio instalado en una máquina remota. Cuando alguno de estos desarrolladores quiere realizar un cambio en una determinada parte del código, echa un cerrojo sobre aquellos ficheros que va a modificar. Tras realizar los cambios oportunos en estos ficheros, deberá actualizarlos en el repositorio para que estén disponibles por el resto de desarrolladores.

¿Problemas?. A la hora de subir los cambios en el repositorio remoto puede que algún otro desarrollador haya tocado algún fichero que hace que el proyecto no compile. Aunque sería una buena práctica de desarrollo en equipo que estas cosas no pasasen, en la realidad pasan. Con sistemas como Subversion el desarrollador tendría que ir fichero a fichero viendo que se ha modificado y adaptar su código.

Con sistemas distribuidos de versionados la cosa funciona de manera diferente. Cada desarrollador tiene su propio repositorio en su máquina local. Este repositorio será privado para el desarrollador y podrá hacer los cambios (el cómo se verá en el siguiente apartado) que él considere oportuno. Una vez hechos estos cambios puede dependiendo de la configuración que se escoja en el sistema de versionado actualizar un repositorio de su propiedad pero del que cualquier otro desarrollador podrá actualizarse o bien tener un repositorio remoto donde todos los desarrolladores podrán descargarse las nuevas versiones (algo similar a lo que pasaba con los sistemas centralizados de versionado).

Una gran ventaja de Git (y de los sistemas distribuidos en general) es que podemos configurar nuestros repositorios de múltiples formas y así tenemos la arquitectura que más nos convenga en función de la naturaleza de nuestro proyecto: tipo de metodología utilizada, número de desarrolladores, infraestructura disponible, …

Doble proceso de comit

A diferencia de otros sistemas de versionado, en Git tenemos que realizar dos operaciones para hacer un commit. Aunque en principio parezca que le añada más complejidad, el hecho es que son más las ventajas que los inconvenientes. Para entender mejor el proceso de commit vamos a explicar las distintas fases que se dan en Git:

  • Modified Un fichero está marcado como modified cuando éste se ha modificado pero todavía no ha sido comitted sobre el repositorio.
  • Staged Es un estado intermedio, donde se indica que un fichero ésta listo para ser guardado (commited) en el repositorio.
  • Commited Significa que un fichero está almacenado en nuestro repositorio.

¿Qué quieren decir estas tres fases?. Imaginemos que estamos trabajando con un determinado número de ficheros en nuestro directorio de trabajo Git. Al modificar estos ficheros pasarán a tener un estado ‘modified’. Si queremos hacer un commit sobre nuestro repositorio local primero habría que realizar un paso intermedio. Este paso consiste en marcar a los ficheros como ‘staged’. Cuando marcamos un fichero como staged quiere decir que añadimos el fichero a un índice que nos almacena una referencia a dicho fichero modificado. Los ficheros que están marcados como staged pueden ser agrupados en distintos snapshots. En la fase staged podemos agrupar los ficheros en diferentes snapshots en función de cómo decidamos. Finalmente podemos hacer commit de los ficheros de la anterior fase.

Estados en Git

Estados en Git

¿Cuál es la ventaja de este enfoque?. Imaginar que estamos tocando código y de repente queremos hacer un commit de una serie de ficheros, pero en el último momento nos damos cuenta que hay algún fichero que no queremos subir porque hemos encontrado que por ejemplo no necesitamos inclurlo aún. Con Git lo que podemos hacer es desestimar este fichero y hacer el snapshot únicamente con los ficheros que creamos convenientes. Así cuando recuperemos posteriormente veremos modificados sólo los ficheros fichero que queramos. Pero ojo, … en el fichero desestimado no habremos perdido los cambios porque ya lo hemos incluído como staged. Es decir, podemos crear un snapshot en el que está ese fichero con su versión anterior no modificada. Pero al mismo tiempo tendremos acceso a las modificaciones realizadas que no se han querido incluir en el snapshot.

La verdad es que es un poco lioso, una forma de verlo para los de SVN si utilizáis un IDE como Eclipse es la siguiente. Imaginaros que el repositorio remoto donde os sincronizaís es vuestro repositorio local (estado similar commited). Vuestro directorio de trabajo local, es vuestro proyecto creado a partir de un checkout sobre el que hacéis cambios (estado similar modified). Como ya hemos dicho SVN no tiene estado staged, podemos decir que en Eclipse para SVN habría, entre muchas comillas lo que voy a decir, algo similar al estado staged. ¿Dónde?. En el historial local del fichero. Aquí podemos ver las copias del fichero almacenadas cada cierto tiempo. Obviamente no es lo mismo que Git, en Git los ficheros marcados como staged son accesibles desde su Api de línea de comandos. Esta comparación es como todas odiosa, pero si a alguien le sirve para entender un poco mejor como funciona Git bienvenida sea, si no … 1, 2, 3 … olvidala.

Identificador de commit

Como hemos dicho en Git no hay noción de cambio de un fichero. Todo funciona en base a snapshots. Por lo tanto no existen los números de versión igual que en SVN. En lugar de ello, existe lo que se llama commit ID. Estos identificadores están asociados a un snapshot. El identificador no es otra cosa que un Hash generado a partir del snapshot creado y ciertos metadatos. Una ventaja de tener un Hash como identificador en lugar de un valor numérico es que tenemos integridad de datos en nuestros snapshots. Si por cualquier motivo algún fichero se corrompe nos podríamos dar cuenta ya que el Hash no sería el mismo.

Todas las imagenes de este post las he cogido del blog perteneciente al libro de Apress ProGit.

En el siguiente post vamos a hablar de GitHub, un hosting en modalidad libre y de pago, que permite subir nuestro código y gestionar mediante Git su versionado.

 
3 comentarios

Publicado por en 24 agosto, 2011 en GIT, SCM, SVN

 

Etiquetas: , , , ,

3 Respuestas a “Arquitectura de Git

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

 
A %d blogueros les gusta esto: