Sistema de control de versiones

¿ Qué es el sistema de control de versiones?

El control de versiones es un sistema que registra los cambios realizados sobre un archivo o conjunto de ellos a lo largo del tiempo, de modo que puedas recuperar versiones especificas mas adelante.

Ejemplos de algunos sistemas de control de versiones:

• CVS
• Subversión
• SourceSafe
• Darcs
• Plastic SCM
• Git
• Mercurial

Todos los sistemas de control de versiones(VCS), nos proporcionan:

• modos de almacenamientos de la  información(código fuente,archivos..)
• posibilidad de cambios sobre esos elementos(añadir,borrar,mover,etc)
• crear informes del estado de los archivos
• registro histórico(de los cambios realizados,versiones anteriores y permite volver a un estado de  versión anterior)
• Se diferencian 2 tipos de VCS los centralizados y los  distribuidos.

Sistema de control de versiones Centralizados:

Existe un repositorio centralizado con todo el  código con un  único administrador,todas las  decisiones importantes necesitan la  aprobación del responsable.

Estos sistemas, como CVS,Subversion y perforce, tienen un único servidor que contiene todos los archivos versionados y varios clientes que descargan los archivos de ese lugar central.Durante muchos años, este ha sido el estándar para el control de versiones.

desventajas:

• Si el servidor se cae durante una hora, entonces durante esa hora nadie puede colaborar o guardar cambios versionados de aquello en que estaba trabajando.
• Si el disco duro en el que se encuentra la base de datos central se corrompe y no se han llevado a cabo copias de seguridad adecuadamente,se pierde absolutamente todo.

Sistema de control de versiones Distribuidos(DVCS):

En un DVCS (como Git, Mercurial, Bazaar o Darcs), los clientes no sólo descargan la última instantánea de los archivos: replican completamente el repositorio. Así, si un servidor se cae o "muere", y estos sistemas estaban colaborando a través de él, cualquiera de los repositorios de los clientes se pueden copiar en el servidor para restaurarlo.

Se pueden crear diferentes grupos de personas, manteniendo la coordinación y trabajar de manera simultanea.

Esto permite establecer varios tipos de flujos de trabajo que NO son posibles en sistemas centralizados, como pueden ser los modelos jerárquicos.

Git como SVC:

Git, es un sistema de control de versiones (SVC) distribuido, creado por Linus Torvalds, que  gestiona los cambios del software, nos facilita la adminitraciòn de los  distintos cambios que se realizan en nuestro proyecto.

Ventajas:

• Velocidad
• Diseño sencillo
• Fuerte apoyo al desarrollo no lineal (miles de ramas paralelas)
• Completamente distribuido
• Capaz de manejar grandes proyectos como el núcleo de Linux de manera eficiente (velocidad y tamaño de los datos)

¿Porque Git y no otro sistema de control de versiones?

Aparte de que Git es un sistema de control de versiones distribuido, otra  principal diferencia entre Git y cualquier otro VCS (Subversion y compañía incluidos) es cómo Git modela sus datos.La mayoría de los demás sistemas almacenan la información como una lista de cambios en los archivos, como en la siguiente figura:

Otros sistemas tienden a almacenar los datos como cambios de cada archivo respecto a una versión base.

Git modela sus datos más como un conjunto de instantáneas de un mini sistema de archivos. Cada vez que confirmas un cambio, o guardas el estado de tu proyecto en Git, él básicamente hace una foto del aspecto de todos tus archivos en ese momento, y guarda una referencia a esa instantánea. Para ser eficiente, si los archivos no se han modificado, Git no almacena el archivo de nuevo — sólo un enlace al archivo anterior idéntico que ya tiene almacenado, como en la siguiente figura:

Los 3 estados de Git

Git tiene tres estados principales en los que se pueden encontrar tus archivos: confirmado (committed), modificado (modified), y preparado (staged). Confirmado significa que los datos están almacenados de manera segura en tu base de datos local. Modificado significa que has modificado el archivo pero todavía no lo has confirmado a tu base de datos. Preparado significa que has marcado un archivo modificado en su versión actual para que vaya en tu próxima confirmación(commit).

Esto nos lleva a las tres secciones principales de un proyecto de Git: el directorio de Git (Git directory), el directorio de trabajo (working directory), y el área de preparación (staging area).

Directorio de trabajo, área de preparación, y directorio de Git

                            

El directorio de Git es donde Git almacena los metadatos y la base de datos de objetos para tu proyecto. Es la parte más importante de Git, y es lo que se copia cuando clonas un repositorio desde otro ordenador.

El directorio de trabajo es una copia de una versión del proyecto. Estos archivos se sacan de la base de datos comprimida en el directorio de Git, y se colocan en disco para que los puedas usar o modificar.

El área de preparación es un sencillo archivo, generalmente contenido en tu directorio de Git, que almacena información acerca de lo que va a ir en tu próxima confirmación. A veces se denomina el índice, pero se está convirtiendo en estándar el referirse a ello como el área de preparación.

El flujo de trabajo básico en Git es algo así:

1. Modificas una serie de archivos en tu directorio de trabajo.
2. Preparas los archivos, añadiendo instantáneas de ellos a tu área de preparación.
3. Confirmas los cambios, lo que toma los archivos tal y como están en el área de preparación, y almacena esa instantánea de manera permanente en tu directorio de Git.

Si una versión concreta de un archivo está en el directorio de Git, se considera confirmada (committed). Si ha sufrido cambios desde que se obtuvo del repositorio, pero ha sido añadida al área de preparación, está preparada (staged). Y si ha sufrido cambios desde que se obtuvo del repositorio, pero no se ha preparado, está modificada (modified). 

Estado de los archivos en Git

Cada archivo que se encuentra en el direciorio de trabajo puede estar en uno de 2 estados:

• Tracked(rastreado por Git) :

            Son aquellos archivos que fueron commiteados o son aquellos que fueron clonados de un proyecto que ya estaba en marcha.Los archivos tracked que no han sido modificados son unmodifieded(no han sido modificados), si se editan o cambia  algún archivo, pasan a ser modified(modificados),si se usa el comando git add para añadir esos archivos modified, entonces se dice que estan en el staged, listos para se commiteados.

•  untracked(no rastreado por Git):

          Son aquellos archivos que fueron recién creados en nuestro directorio local y por lo tanto no esta siendo seguido por Git, y es un archivo que no se ha commiteado, una vez que sea haga un commit sobre el o se suba al repositorio local, entonces estara Tracked.

En la siguiente figura se muestra este ciclo.

Fuente: http://git-scm.com/ (pagina oficial de git)