GITControl de Versiones

Héctor Sandoval OrmeñoIngeniería en Redes y Telecomunicaciones

Universidad Arturo Prat

¿Que es control de versiones?Se llama control de versiones a la gestión de los diversos cambios que se realizan sobre los elementos de algún producto o una configuración del mismo. Una versión, revisión o edición de un producto, es el estado en el que se encuentra el mismo en un momento dado de su desarrollo o modificación.

Aunque un sistema de control de versiones puede realizarse de forma manual, es muy aconsejable disponer de herramientas que faciliten esta gestión dando lugar a los llamados sistemas de control de versiones o VCS (del inglés Version Control System). Ejemplos de este tipo de herramientas son entre otros: CVS, Subversion, SourceSafe, ClearCase, Darcs, Bazaar, Plastic SCM, Git, Mercurial, Perforce, Fossil SCM.

El control de versiones se realiza principalmente en la industria informática para controlar las distintas versiones del código fuente dando lugar a los sistemas de control de código fuente o SCM (siglas del inglés Source Code Management). Sin embargo, los mismos conceptos son aplicables a otros ámbitos como documentos, imágenes, sitios web, etc.

¿Debo yo usar control de versiones?Excusas para NO usar control de versiones:

• No programo.

• No soy parte de un equipo de desarrollo.

• No necesito versiones de lo que hago.

• Tengo 3 copias en 3 discos distintos, un DVD y un pendrive.

• No tengo $$ para montar un servidor de versiones.

• Nunca trabajamos en el mismo código al mismo tiempo.

Ese momento incomodo

cuando te das cuenta que

sobrescribiste un archivo

nuevo con una versión anterior

• Cambio ("change", "diff", "delta")

• Lista de cambios ("changelist", "change set", "patch")

• Exportación ("export")

• Importación ("import")

• Integración o fusión ("merge")

• Integración inversa

• Actualización ("sync" ó “update")

• Copia de trabajo (“workspace”)

• Congelar

CONCEPTOS• Repositorio

• Módulo

• Revisión ("version")

• Rotular ("tag")

• Línea base ("Baseline")

• Abrir rama ("branch") o ramificar

• Desplegar ("Check-out", "checkout", "co")

• "Publicar" o "Enviar" ("commit", "check-in", "ci", "install", “submit")

• Conflicto

• Resolver

¿GIT?Es un software de control de versiones diseñado por Linus Torvalds, pensando en la eficiencia y la confiabilidad del mantenimiento de versiones de aplicaciones cuando estas tienen un gran número de archivos de código fuente. Al principio, Git se pensó como un motor de bajo nivel sobre el cual otros pudieran escribir la interfaz de usuario o front end. Sin embargo, Git se ha convertido desde entonces en un sistema de control de versiones con funcionalidad plena. Hay algunos proyectos de mucha relevancia que ya usan Git, en particular, el grupo de programación del núcleo Linux.

git initIngresar a la carpeta donde queremos crear nuestro repositorio y digitar:

$ git init

esto creará la carpeta vacía para nuestro repositorio.

git checkoutCrea una copia local del repositorio ejecutando

$ git clone /ruta/al/repositorio

Si utilizas un servidor remoto, ejecuta

$git clone username@host:/ruta/al/repositorio

git addPuedes registrar cambios (añadirlos al Index) usando

$ git add <archivo>

$ git add .

Este es el primer paso en el flujo de trabajo básico.

Si deseas agregar todos los cambios, puedes usar

$ git add . -A

Tu repositorio local esta compuesto por tres "árboles" administrados por git. El primero es tu Directorio de trabajo que contiene los archivos, el segundo es el

Index que actúa como una zona intermedia, y el último es el HEAD que apunta al último commit realizado.

git commit$ git commit -m “comentario”

-m indica que será la rama “maestra”. Ahora el archivo esta incluido en el HEAD, pero aún no en tu repositorio remoto.

git pushTus cambios están ahora en el HEAD de tu copia local. Para enviar estos cambios a tu repositorio remoto ejecuta

$ git push origin master

Reemplaza master por la rama a la que quieres enviar tus cambios.

Si no has clonado un repositorio ya existente y quieres conectar tu repositorio local a un repositorio remoto, usa

$ git remote add origin <server>

Ahora podrás subir tus cambios al repositorio remoto seleccionado.

Las ramas son utilizadas para desarrollar funcionalidades aisladas unas de otras. La rama master es la rama "por defecto" cuando creas un

repositorio.

Crea nuevas ramas durante el desarrollo y fusiónalas a la rama principal cuando termines.

Crea una nueva rama llamada "caracteristica_x" y cámbiate a ella usando

$ git checkout -b caracteristica_x

vuelve a la rama principal

$ git checkout master

y borra la rama

$ git branch -d caracteristica_x

Una rama nueva no estará disponible para los demás a menos que subas (push) la rama a tu repositorio remoto

$ git push origin <branch>

ACTUALIZAR Y FUSIONARPara actualizar tu repositorio local al commit más nuevo, ejecuta

$ git pull

en tu directorio de trabajo para bajar y fusionar los cambios remotos. Para fusionar otra rama a tu rama activa (por ejemplo master), utiliza

$ git merge <rama>

en ambos casos git intentará fusionar automáticamente los cambios. Desafortunadamente, no siempre será posible y se podrán producir conflictos. Tú eres responsable de fusionar esos conflictos manualmente al editar los archivos mostrados por git. Después de modificarlos, necesitas marcarlos como fusionados con

git add <archivo>

Antes de fusionar los cambios, puedes revisarlos usando

git diff <rama original> <rama objetivo>

ETIQUETASSe recomienda crear etiquetas para cada nueva versión publicada de un software. Este concepto no es nuevo, ya que estaba disponible en SVN.

Puedes crear una nueva etiqueta llamada 1.0.0 ejecutando

$ git tag 1.0.0 1b2e1d63ff

1b2e1d63ff se refiere a los 10 caracteres del commit id al cual quieres referirte con tu etiqueta. Puedes obtener el commit id con

$ git log

también puedes usar menos caracteres que el commit id, pero debe ser un valor único.

REEMPLAZANDO LOS CAMBIOS LOCALES

En caso de que hagas algo mal puedes reemplazar cambios locales usando el comando

$ git checkout -- <archivo>

Este comando reemplaza los cambios en tu directorio de trabajo con el último contenido de HEAD. Los cambios que ya han sido agregados al Index, así como también los nuevos archivos, se mantendrán sin cambio.

Por otro lado, si quieres deshacer todos los cambios locales y commits, puedes traer la última versión del servidor y apuntar a tu copia local principal de esta forma

$ git fetch origin

$ git reset --hard origin/master

GITHUBGitHub es una forja para alojar proyectos utilizando el sistema de control de versiones Git. Utiliza el framework Ruby on Rails por GitHub, Inc.

El código se almacena de forma pública, aunque también se puede hacer de forma privada, creando una cuenta de pago.

BITBUCKETBitbucket es un servicio de alojamiento basado en web, para los proyectos que utilizan el sistema de control de revisiones Mercurial y Git. Bitbucket ofrece planes comerciales y gratuitos. Se ofrece cuentas gratuitas con un número ilimitado de repositorios privados (que puede tener hasta cinco usuarios en el caso de cuentas gratuitas), los repositorios privados no se muestran en las páginas de perfil - si un usuario sólo tiene depósitos privados, el sitio web dará el mensaje "Este usuario no tiene repositorios".

SOURCETREEEs un cliente GUI con versiones para MAC y WINDOWS, con el cual se puede:

• Crear y clonar repositorios de cualquier sitio, tanto Git como Mercurial. Además de integrarse perfectamente con Bitbucket o Github.

• Commit, push, pull y merge de nuestros archivos

• Detectar y resolver conflictos

• Consultar el historial de cambios de nuestros repositorios.

GLOSARIO• Forja : Una forja es una plataforma de desarrollo colaborativo de software. Se enfoca hacia la cooperación entre

desarrolladores para la difusión de software y el soporte al usuario.En este tipo de plataformas se albergan múltiples proyectos de software, en los que los desarrolladores han de registrarse para poder contribuir. Consta de numerosas aplicaciones normalmente con interfaz web para la administración y desarrollo de estos proyectos en común.

• Repositorio : Es el lugar en el que se almacenan los datos actualizados e históricos de cambios, a menudo en un servidor. A veces se le denomina depósito o depot. Puede ser un sistema de archivos en un disco duro, un banco de datos, etc.

• Módulo : Conjunto de directorios y/o archivos dentro del repositorio que pertenecen a un proyecto común.

• Revisión : es una versión determinada de la información que se gestiona. Hay sistemas que identifican las revisiones con un contador (Ej. subversion). Hay otros sistemas que identifican las revisiones mediante un código de detección de modificaciones (Ej. Git usa SHA1). A la última versión se le suele identificar de forma especial con el nombre de HEAD. Para marcar una revisión concreta se usan los rótulos o tags

• Rotular : Darle a alguna versión de cada uno de los ficheros del módulo en desarrollo en un momento preciso un nombre común ("etiqueta" o "rótulo") para asegurarse de reencontrar ese estado de desarrollo posteriormente bajo ese nombre. En la práctica se rotula a todos los archivos en un momento determinado. Para eso el módulo se "congela" durante el rotulado para imponer una versión coherente. Pero bajo ciertas circunstancias puede ser necesario utilizar versiones de algunos ficheros que no coinciden temporalmente con las de los otros ficheros del módulo. Los tags permiten identificar de forma fácil revisiones importantes en el proyecto. Por ejemplo se suelen usar tags para identificar el contenido de las versiones publicadas del proyecto. En algunos sistemas se considera un tag como una rama en la que los ficheros no evolucionan, están congelados.

GLOSARIO• Línea base : Una revisión aprobada de un documento o fichero fuente, a partir del cual se pueden realizar

cambios subsiguientes.

• Abrir rama ("branch") o ramificar : Un módulo puede ser branched o bifurcado en un instante de tiempo de forma que, desde ese momento en adelante se tienen dos copias (ramas) que evolucionan de forma independiente siguiendo su propia línea de desarrollo. El módulo tiene entonces 2 (o más) "ramas". La ventaja es que se puede hacer un "merge" de las modificaciones de ambas ramas, posibilitando la creación de "ramas de prueba" que contengan código para evaluación, si se decide que las modificaciones realizadas en la "rama de prueba" sean preservadas, se hace un "merge" con la rama principal. Son motivos habituales para la creación de ramas la creación de nuevas funcionalidades o la corrección de errores.

• Desplegar ("Check-out", "checkout", “co") : Un despliegue crea una copia de trabajo local desde el repositorio. Se puede especificar una revisión concreta, y predeterminadamente se suele obtener la última.

• "Publicar" o "Enviar" ("commit", "check-in", "ci", "install", “submit" : Un commit sucede cuando una copia de los cambios hechos a una copia local es escrita o integrada sobre el repositorio.

• Conflicto : Un conflicto ocurre en las siguientes circunstancias: Los usuarios X e Y despliegan versiones del archivo A en que las líneas n1 hasta n2 son comunes.,El usuario X envía cambios entre las líneas n1 y n2 al archivo A,El usuario Y no actualiza el archivo A tras el envío del usuario X, El usuario Y realiza cambios entre las líneas n1 y n2, El usuario Y intenta posteriormente enviar esos cambios al archivo A, El sistema es incapaz de fusionar los cambios. El usuario Y debe resolver el conflicto combinando los cambios, o eligiendo uno de ellos para descartar el otro.

GLOSARIO• Resolver : El acto de la intervención del usuario para atender un conflicto entre diferentes

cambios al mismo archivo.

• Cambio ("change", "diff", “delta") : representa una modificación específica a un archivo bajo control de versiones. La granularidad de la modificación considerada un cambio varía entre diferentes sistemas de control de versiones.

• Lista de cambios ("changelist", "change set", “patch") : En muchos sistemas de control de versiones con commits multi-cambio atómicos, una lista de cambios identifica el conjunto de cambios hechos en un único commit. Esto también puede representar una vista secuencial del código fuente, permitiendo que el fuente sea examinado a partir de cualquier identificador de lista de cambios particular.

• Exportación (“export”) : Una exportación es similar a un check-out, salvo porque crea un árbol de directorios limpio sin los metadatos de control de versiones presentes en la copia de trabajo. Se utiliza a menudo de forma previa a la publicación de los contenidos.

• Importación (“import") : Una importación es la acción de copia un árbol de directorios local (que no es en ese momento una copia de trabajo) en el repositorio por primera vez.

GLOSARIO• Integración o fusión (“merge") : Una integración o fusión une dos conjuntos de cambios sobre un fichero o

un conjunto de ficheros en una revisión unificada de dicho fichero o ficheros. Esto puede suceder cuando un usuario, trabajando en esos ficheros, actualiza su copia local con los cambios realizados, y añadidos al repositorio, por otros usuarios. Análogamente, este mismo proceso puede ocurrir en el repositorio cuando un usuario intenta check-in sus cambios. Puede suceder después de que el código haya sido branched, y un problema anterior al branching sea arreglado en una rama, y se necesite incorporar dicho arreglo en la otra. Puede suceder después de que los ficheros hayan sido branched, desarrollados de forma independiente por un tiempo, y que entonces se haya requerido que fueran fundidos de nuevo en un único trunk unificado.

• Integración inversa : El proceso de fundir ramas de diferentes equipos en el trunk principal del sistema de versiones.

• Actualización ("sync" ó “update") : Una actualización integra los cambios que han sido hechos en el repositorio (por ejemplo por otras personas) en la copia de trabajo local.

• Copia de trabajo (“workspace”) : La copia de trabajo es la copia local de los ficheros de un repositorio, en un momento del tiempo o revisión específicos. Todo el trabajo realizado sobre los ficheros en un repositorio se realiza inicialmente sobre una copia de trabajo, de ahí su nombre. Conceptualmente, es un cajón de arena o sandbox.

• Congelar : significa permitir los últimos cambios (commits) para solucionar las fallas a resolver en una entrega (release) y suspender cualquier otro cambio antes de una entrega, con el fin de obtener una versión consistente. Si no se congela el repositorio, un desarrollador podría comenzar a resolver una falla cuya resolución no está prevista y cuya solución dé lugar a efectos colaterales imprevistos.

BIBLIOGRAFIA• http://es.wikipedia.org/wiki/Git

• http://es.wikipedia.org/wiki/Control_de_versiones

• http://rogerdudler.github.io/git-guide/index.es.html

• http://git-scm.com/book/es/v1/Empezando-Fundamentos-de-Git

• http://www.sbf5.com/~cduan/technical/git/

• http://juristr.com/blog/2013/04/git-explained/

• http://marklodato.github.io/visual-git-guide/index-es.html

• http://geek-and-poke.com/