Introduccion a VCS
Sistemas de Control de Versiones (VCS)
Un sistema de control de versiones es una herramienta que registra los cambios realizados en un archivo o conjunto de archivos a lo largo del tiempo, permitiendo recuperar versiones especificas mas adelante.
Tipos de Control de Versiones
- Local (LVCS)
- Centralizado (CVCS)
- Distribuido (DVCS)
Ejemplo
Si eres diseñador gráfico o de web y quieres mantener cada versión de una imagen o diseño, usar un sistema de control de versiones es una decisión muy acertada. Dicho sistema te permite regresar a versiones anteriores de tus archivos, regresar a una versión anterior del proyecto completo, comparar cambios a lo largo del tiempo, ver quién modificó por última vez algo que pueda estar causando problemas, ver quién introdujo un problema y cuándo, y mucho más. Usar un VCS también significa generalmente que si arruinas o pierdes archivos, será posible recuperarlos fácilmente. Adicionalmente, obtendrás todos estos beneficios a un costo muy bajo.
Sistemas de Control de Versiones Locales
Problema
Un metodo de control de versiones, usado por muchas personas, es copiar archivos a otro directorio. Pero es facil olvidar en que directorio te encuentras y guardar accidentalmente en el archivo equivocado o sobreescribir archivos que no querias.
Solucion
Los LVCS contenian una simple base de datos, en la que se llevaba el registro de todos los cambios realizados a los archivos. Una de las herramientas de control de versiones mas popular fue un sistema llamado RCS, que todavia podemos encontrar en muchas de las computadoras actuales.
Sistemas de Control de Versiones Centralizados
Problema
El siguiente gran problema con el que se encuentran las personas es que necesitan colaborar con desarrolladores en otros sistemas.
Solucion
Los CVCS fueron desarrollados para implementar la colaboracion. Estos sistemas tienen un unico servidor que contiene todos los archivos versionados y varios clientes que descargan los archivos desde ese lugar central. Este ha sido el estandar para el control de versiones por muchos años.
Sistemas de Control de Versiones Distribuido
Problema
Usar un CVCS tiene serias desventajas. La mas obvia es el punto unico de fallo que representa el servidor central. Si el servidor se cae, nadie podra colaborar o guardar cambios. Si el disco duro del servidor central se corrompe, se perdera toda la informacion del proyecto.
Solucion
En un DCVS los clientes no solo descargan la ultima copia instantanea de los archivos, sino que se replica completamente el repositorio. De esta manera, si un servidor deja de funcionar y estos sistemas estaban colaborando a traves de el, cualquiera de los repositorios disponibles en los clientes puede ser copiado al servidor con el fin de restaurarlo.
Historia de Git Resumida
Como muchas de las grandes cosas en esta vida, Git comenzó con un poco de destrucción creativa y una gran polémica.
El kernel de Linux es un proyecto de software de código abierto con un alcance bastante amplio. Durante la mayor parte del mantenimiento del kernel de Linux (1991-2002), los cambios en el software se realizaban a través de parches y archivos. En el 2002, el proyecto del kernel de Linux empezó a usar un DVCS propietario llamado BitKeeper.
En el 2005, la relación entre la comunidad que desarrollaba el kernel de Linux y la compañía que desarrollaba BitKeeper se vino abajo y la herramienta dejó de ser ofrecida de manera gratuita. Esto impulsó a la comunidad de desarrollo de Linux (y en particular a Linus Torvalds, el creador de Linux) a desarrollar su propia herramienta basada en algunas de las lecciones que aprendieron mientras usaban BitKeeper. Algunos de los objetivos del nuevo sistema fueron los siguientes:
- Velocidad
- Diseño sencillo
- Gran soporte para desarrollo no lineal (miles de ramas paralelas)
- Completamente distribuido
- Capaz de manejar grandes proyectos (como el kernel de Linux) eficientemente
Desde su nacimiento en el 2005, Git ha evolucionado y madurado para ser fácil de usar y conservar sus características iniciales. Es tremendamente rápido, muy eficiente con grandes proyectos y tiene un increíble sistema de ramificación para desarrollo no lineal
Fundamentos de Git (parte 1)
Estados y Configuracion¿Que es Git?
Git almacena y maneja la informacion de forma muy diferente a los otros VCSs, a pesar de que su interfaz es bastante similar. Comprender lo que diferencia a git es fundamental para no confundirse a la hora de usarlo.
Copias instantaneas, no diferencias
La principal diferencia entre Git y cualquier otro VCS es la forma en la que manejan sus datos. Conceptualmente, la mayoria de los otros sitemas almacenan la informacion como una lista de cambios en los archivos (deltas). Estos sistemas manejan la informacion que almacenan como un conjunto de archivos y las modificaciones hechas a cada uno de ellos a traves del tiempo.
Git no maneja ni almacena diferencias (deltas), en su lugar almacena un conjunto de copias instantaneas (snapshots) de un sistema de archivos miniatura. Cada vez que confirmas un cambio, o guardas el estado de tu proyecto en Git, se toma una foto del aspecto de todos tus archivos en ese momento y guarda una referencia a esa spanshot. Si el archivo no se modifico desde la ultima version, Git guarda un enlace al archivo anterior identico que ya tiene almacenado (una referencia que ocupa poca memoria).
Deltas vs Snapshots
Ventajas de Git
1. Casi todas las operaciones son locales
La mayoria de las operaciones en Git solo necesitan archivos y recursos locales para funcionar. Por lo general no se necesita informacion de ningun otro computador de tu red. (En un CVCS se podrian experimentar retrasos en los comandos, ya que necesitan viajar por la red)
2. Git tiene integridad
Todo en Git es verificado mediante suma de comprobacion (checksum) antes de ser almacenado, esto hace que no puedas perder informaicon durante la transmision o sufrir corrupcion de archivos sin que Git sea capaz de detectarlo. El mecanismo que usa Git para el checksum se conoce como hash SHA-1 y se ve algo asi:
24b9da6552252987aa493b52f8696cd6d3b00373
Ver estos valores hash en todos lados en Git es muy comun. De hecho, Git no guarda todo por nombre de archivo, sino por el valor hash de sus contenidos.
3. Git generalmente solo añade informacion
Cuando realizas acciones en Git, casi todas ellas solo añaden informacion a la base de datos de Git. Es muy dificil conseguir que el sistema haga algo que no se pueda enmendar/revertir, o que de algun modo borre informacion.
Gracias a esto podemos experimentar sin el peligro de estropear gravemente las cosas en nuestro proyecto.
Los 3 estados (¡Muy importante!)
Git tiene 3 estados principales en los que se pueden encontrar tus archivos:
- committed: Confirmado, significa que los datos estan almacenados de manera segura en la base de datos local.
- modified: Modificado, significa que has modificado el archivo pero todavia no lo has confirmado en tu base de datos.
- staged: Preparado, significa que has marcado un archivo modificado en su version actual para que vaya en tu proxima confirmacion.
Esto nos lleva a las 3 secciones/areas principales de un proyecto de Git:
- Git Directory: El directorio de git o Repositorio, es la carpeta
.git/. - Working Directory: El directorio de trabajo, donde esta nuestro proyecto.
- Staging Area: El area de preparacion, donde selecionaremos que archivos incluir en nuestra confirmacion.
Las 3 areas
El directorio de Git es donde se almacenan los metadatos y la base de datos de objetos para tu proyecto. Es la parte mas importante de Git, y es lo que se copia cuando clonas un repositorio desde otra computadora.
El directorio de trabajo es una copia de una version del proyecto. Estos archivos se sacan de la base de datos comprimida en el directorio de Git.
El area de preparacion es un archivo, generalmente contenido en tu directorio de Git (.git/),
que almacena informacion de que es lo que va a ir en tu proxima confirmacion.
Instalar Git
No lo veremos en detalle, ya que las guias son bastante simples. Ver links de instalacion.
Configuracion de Git
Este proceso es necesario solamente una vez en tu computadora. Luego la configuracion se mantendra entre actualizaciones, tambien se pueden cambiar en cualquier momento ejecutando los comandos correspondientes.
Git trae una herramienta llamada git config, que te permite obtener y establecer variables de configuracion
que controlan el aspecto y funcionamiento de Git. Estas variables pueden almacenarse en 3 sitios distintos:
/etc/gitconfig: Contiene valores para todos los usuarios del sistema y todos sus repositorios. Si pasas la opcion--system, el comando lee y escribe especificamente este archivo.~/.gitconfigo~/.config/git/config: Este archivo es especifico de tu usuario. Puedes hacer que Git lea y escriba especificamente este archivo usando la opcion--global..git/config: Este archivo es especifico del repositorio actual, es el valor por defecto si no pasas ninguna opcion.
Cada nivel sobre-escribe los valores del nivel anterior, por lo que los valores de
.git/configtiene preferencia por sobre los de/etc/gitconfig
Tu Identidad
Lo primero que deberas hacer cuando instales Git es establecer tu nombre de usuario y direccion de correo. Esto es importante porque los commits usan esta informacion, y es introducida de manera inmutable en los commits que envias.
git config --global user.name "Jhon Doe"git config --global user.email johndoe@example.comTu editor
Puedes elegir el editor de texto por defecto que se utilizara cuando Git necesite que introduzcas un mensaje. Si no indicas nada, Git ysara el editor por defecto de tu sistema, que generalmente en Vim.
git config --global core.editor codeComprobar configuracion
Puedes usar el comando git config --list para mostrar todas las propiedades que Git ha configurado:
Tambien puedes comprobar el valor que Git utilizara para una clave especifica ejecutando git config <key>:
¿Como obtener ayuda?
Si alguna vez necesitas ayuda usando Git, existen 3 formas de ver la pagina del manual (manpage) para cualquier comando de Git:
git help <verb>git <verb> --helpman git-<verb>
Por ejemplo, puedes ver la pagina del manual para el comando config ejecutando git help config.
Recursos
- Pro Git - Cap. 1: Desde
1.1a1.8(todo el capitulo 1)
1 / 1