Los sistemas de control de versiones son la forma más práctica de darle seguimiento a un proyecto, ya sea de software o de otra índole digital. En el caso de la pérdida parcial de tu proyecto o de introducir algún error en el mismo (somos humanos después de todo), no interesa poder recuperar información o restaurarla a un estado anterior. Es por esto que saber de Sistemas de Control de Versiones es algo imprescindible para llevar a cabo un proyecto. Permite gestionar las colaboraciones entre las partes, y además darle seguridad al equipo que desarrolla. Veremos por qué Git es el SCV por excelencia, y que lo destaca de los demás sistemas. Este pequeño análisis es un resumen del libro Pro Git, de la página web de Git. Esto lo escribo con el carácter de aprender, más que nada para poder fortalecer mis dotes comunicativas y de aprendizaje. Comencemos describiendo algunos de estos sistemas de control de versiones.
sistemas de control de versiones locales
Es común el Copiar-Pegar los archivos que te interesan salvar en un medio extraíble o en un disco o subirlos a la nube de forma manual. Pero esto es altamente ineficiente y propenso a errores, archivos duplicados, desorden, olvidarse de pasar algo, borrar algo por un descuido. Es por eso que los programadores han resuelto esto haciendo uso de programas que hacen esto más simple. Haciendo uso de bases de datos sencillas hacen el seguimiento de cambios en archivos para llevar un registro. La mayoría de sistemas operativos tiene sistemas de backup incluidos.
Sistemas de control centralizados
El problema viene cuando varios programadores trabajan en un mismo proyecto. Donde todos los archivos están centralizados en un mismo servidor, y tiene varios clientes que descargan/cargan archivos de el. La ventajas con respecto a los CVS locales, es que los desarrolladores saben hasta cierto punto dónde y en que están trabajando los otros colaboradores. Los administradores del servidor y del proyecto tienen amplio control sobre lo que se hace en el proyecto. Las desventajas es que el servidor central presenta un punto único de fallo, por lo que cuando este se cae nadie puede realizar cambios en los archivos que están trabajando. Si el disco duro falla y no se realizaron copias de seguridad adecuadas entonces todo el trabajo hasta el momento se pierde, o su totalidad. Es similar a tener todo el en el mismo lugar se corre el riesgo de perderlo todo.
Sistemas de Control de Versión Distribuidos
En estos sistemas el servidor se distribuye entre los clientes, por lo que si ocurriese algo en alguno de los servidores tanto centralizados como los distribuidos se pueden recuperar. Cada clon del sistema tiene la posibilidad de restaurar a otro o actualizar la información de un cambio. Además de manejar de distintas maneras el proyecto permitiendo definir el mejor flujo de trabajo dentro del proyecto que mejor se adapte a las necesidades. Se pueden crear varias jerarquías de trabajo para la revisión de los mismo.
Breve Historia de Git
Git surge como una solución por parte de Linus torvalds para el proyecto kernel de linux. Los que contribuyen a linux usaban un DVCS llamado BitKeeper el cual dejó de ser gratuito, por lo cual en 2005 nace Git con algunos objetivos en mente:
- Velocidad
- Diseño sencillo
- Soporte para desarrollo no lineal (ramificación)
- Capaz de manejar grandes proyectos, eficientemente.
Desde su nacimiento ha ganado popularidad, ha madurado para ser fácil de usar y es tremendamente rápido, eficiente y tiene un increíble sistema de ramificación para el desarrollo no lineal.
Fundamentos Git
Hay que entender los fundamentos de Git para usarlo de la forma efectiva, en mis comienzos de usar Git, solo lo usaba como una forma de backup de mis trabajos en la facultad y de mostrar alguna resolución de estos. Aprendiendo los fundamentos, aprenderás de las ventajas de Git a la hora de programar y usar sus características a la hora de usarlo.
Copias instantáneas, no diferenciales
La principal diferencia de Git con otros VCSs , el como maneja los datos, la mayoría de VCS guardan la información como una lista de cambios en los archivos. De forma que cada versión es una lista de cambios sobre los archivos.
Git maneja sus cambios como un conjunto de de copias instantáneas del sistema de archivos miniatura. Cada vez que se confirma un cambio o se guarda un estado del proyecto, Git toma una instantánea de los archivos que fueron modificados. Para ser eficiente, solo toma una instantánea de los archivos que fueron modificados en ese momento (compara cambios con la versión anterior), y enlaza a los archivos restantes con el último cambio que fue realizado y almacenado. Ej: archivos de la V1: archivo1, archivo2, archivo3, V2: archivo 1, archivo 2 luego la V2 almacena los cambios de archivo1 y archivo2 y la referencia a archivo 3 de la V1. Por lo que Git almacena sus datos como una secuencia de copias instantáneas.
Esta es una de las razones por la que Git es un cambio en los VCS convencionales que solo ampliaban las características de los anteriores. Además ofrece muchas herramientas construidas sobre Git muy poderosas.
Casi todas las operaciones son locales
GitGitrequiere casi siempre de archivos locales, y por lo general no información en servidores en la red. Por lo que te parecerá que en Git todo es más rápido. Como Git almacena en local, toda la información del proyecto y solo la réplica al servidor central (el repositorio de github) no es necesario información adicional para realizar ninguna operación como sería comparar cambios entre dos estados del servidor, etc. De forma que puedes trabajar sin tener una conexión a Internet. Por lo que puedes trabajar en algún proyecto en algún viaje en avión o en tren, o en tu casa si no cuentas con una buena conexión a Internet.
Git tiene integridad
Todo en Git es verificado con una suma de verificación, lo que hace que Git siempre detecta los cambios en el contenido, no puede sufrir corrupción o pérdida de la información. Esta suma de comprobación se conoce como SHA-1, y se hace en base a el contenido de los archivos o estructura del directorio. Este algoritmo de hash es usado mucho en Git y lo verás con frecuencia.
Por lo general Git solo añade Información
Cuando realizas acciones en Git por lo general se añade información a la base de datos de Git. Es difícil no poder enmendar algo mal hecho en Git. Por lo que se puede perder información y deshacer esos cambios, restaurando alguna de las instancias de cambios anteriores.
Los tres estados
Para entender cómo funciona Git en cuanto a cómo almacena la información en su base de datos, tenemos que entender los tres estados de Git. confirmado (committed), modificado (modified) y preparado(staged). Confirmado es que los datos fueron almacenados en la BD. modificado es que se modificaron archivos y no fueron modificados. Preparado significa que has marcado los archivos para tu próxima confirmación. Por lo que en Git tenemos tres secciones principales en un proyecto.El directorio de Git (Git directory), el directorio de trabajo (working directory), y el área de preparación (staging area).
El repositorio Git es la parte más importante del proyecto, se almacenan los metadatos y las instantáneas del proyecto. Es lo que se copia cuando se clona el proyecto. El directorio de trabajo es una copia de una versión almacenada. Estos archivos son sacados de la última versión almacenada y son usados para modificar. El área de preparación contiene los archivos que van a ir en tu próxima confirmación. El flujo de trabajo en Git es.
- Modificas una serie de archivos en tu directorio de trabajo.
- Preparar los archivos, añadiéndoles a tu área de preparación.
- Confirmar los cambios, tomar los archivos del área de preparación y almacenar una copia instantánea en el directorios de Git.
De forma que cuando estamos modificando un archivo, este estaba en el área de confirmado, y pasó a estar en el área de modificado, y luego se la prepara para confirmar esta en el área de confirmación. Si se modifica y no se prepara está en la etapa de modificación.
Referencias
Imágenes tomadas de el libro de git pro.