6.3.1. Facilita el trabajo con Github

Web de GitHub. Haz clic para acceder a GitHub.
Fuente propia

Git es el sistema de control de versiones utilizado en la web por muchos servidores para alojar sus repositorios remotos, uno de esos casos es el de Github. Github es una plataforma de desarrollo colaborativo de software que utiliza Git para alojar proyectos. Github nos permite, bien abriendo una cuenta de forma gratuita y pública, o bien haciéndolo de forma privada mediante pago, almacenar códigos de proyectos. Mediante la versión pública tendremos acceso a infinidad de repositorios y podremos colaborar con los autores originales de proyectos ofreciéndoles modificaciones o añadidos a dichos programas. A su vez todos nuestros proyectos serán accesibles públicamente para otros desarrolladores de la misma forma. Si por el contrario estamos elaborando un proyecto importante, bajo contrato, o bien bajo patrocinio privado, o que simplemente por motivos personales no queremos que sea difundido tendremos que usar una cuenta privada de pago. En este caso lógicamente dispondremos de más funcionalidades que en el caso de acceso público.

Además de ofrecer el alojamiento de repositorios de forma remota (repositorios remotos), también aporta una interfaz gráfica para el manejo del sistema de control de versiones, lo que facilita el uso del mismo. Podemos pensar el salto que supuso para el usuario pasar de utilizar sistemas operativos mediante la línea de comandos exclusivamente a usarlos con una interfaz gráfica a base de ventanas, iconos, cuadros y listas desplegables, barras de desplazamiento y otros elementos visuales. A modo de ejemplo y de forma exclusivamente aclaratoria, fuera del rigor docente, podríamos pensar que ocurre lo mismo con Git y Github, es decir esta plataforma emplea una interfaz gráfica que evita tener que operar con comandos de Git, siendo mucho más fácil el acceso y la gestión de toda la información. Así, dispone de cuadros gráficos con la secuencia de modificaciones o commits hechas sobre un proyecto indicando fechas, usuarios, etc. de forma directa, o bien por ejemplo de una relación de repositorios con los que estamos trabajando pudiendo pasar más fácilmente de trabajar con unos a hacerlo con otros.

Github es, por tanto, un hosting para el sistema de control de versiones Git, gratuito para proyectos opensource, por lo que puedes utilizarlo para alojar tu repositorio de código y servirte de sus herramientas, que son muy útiles para el trabajo en equipo, destacando entre ellas las siguientes:

  • Una wiki para el mantenimiento de las distintas versiones de las páginas.
  • Un sistema de seguimiento de problemas que permiten a los miembros de tu equipo detallar un problema con tu software o una sugerencia que deseen hacer.
  • Una herramienta de revisión de código, donde se pueden añadir anotaciones en cualquier punto de un fichero y debatir sobre determinados cambios realizados en un commit específico.
  • Un visor de ramas donde se pueden comparar los progresos realizados en las distintas ramas de nuestro repositorio.

Además de eso, puedes contribuir a mejorar el software de los demás.

Pero Github no solo proporciona la gestión de repositorios remotos en internet, también posee una versión de Escritorio: Github Desktop. Esta versión es una aplicación instalable en tu propio ordenador para gestionar tus repositorios locales y comunicarlos con otros remotos.

Vamos a analizar someramente el uso de Github en su versión gratuita en la web.

Lista de verificación.
Imagen en Pixabay de Tumisu bajo licencia CC0 Public Domain

El repositorio de un sistema de control de versiones se organiza en directorios y ficheros, de tal forma que todos los que se refieren a un mismo proyecto constituyen lo que se denomina Módulo.

Hay distintas formas de nombrar las revisiones, es decir, de nombrar las nuevas versiones de un producto original, bien mendiante contadores, códigos o rótulos (tags). Rotular el módulo es nombrar todos los archivos de un proyecto en un momento determinado para reencontrar ese mismo estado de desarrollo en un momento posterior. Para ello es necesario congelar el módulo durante el rotulado. Congelar significa permitir los últimos cambios 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.

El concepto de "Línea Base" (o baseline) es muy intuitivo. A partir de un fichero fuente aprobamos una primera revisión que nos servirá de base para futuras revisiones o modificaciones.

Bifurcación en el bosque.
Imagen en Flickr de Eduard Yanquen con Algunos derechos reservados

De un módulo se pueden tener en un momento dado varias copias (dos o más ramas, branch) que evolucionan de forma independiente siguiendo su propia línea de desarrollo. Es una gran ventaja pues después se puede operar con ellas de diversas formas, por ejemplo fusionándolas (merge).  En general cada persona trabaja en el proyecto creando su propia rama y trabaja en una funcionalidad diferente. Es decir, se diversifican del proyecto principal nuevas ramas con sus propias versiones completas. Cuando cada uno termina de trabajar en su rama, se fusionan la rama actual con la rama “master”. La rama “master” es el directorio principal del proyecto.

Un Despliegue (check-out) crea una copia de trabajo local de los ficheros de un repositorio, en un momento del tiempo o revisión específicos (se puede elegir cualquier revisión pero por defecto se suele tomar de la última). 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.

Se crea un Commit  (check-in) cuando una copia de los cambios hechos a una copia de trabajo local es escrita o integrada en el repositorio. Se está creando en ese punto en el tiempo un punto de control al que se puede volver en caso de necesitar restaurar el proyecto.

También pueden surgir Conflictos cuando el sistema no puede gestionar adecuadamente cambios realizados por dos o más usuarios en un mismo archivo. A veces un usuario tiene que intervenir para Resolver los conflictos originados cuando se realizan cambios en un mismo archivo. Para que una modificación se considere Cambio se tiene que producir bajo un sistema de control de versiones. Una Lista de Cambios puede representar una vista secuencial del código fuente.

Una Exportación es similar a un check-out, es decir es parecido a una copia de trabajo local desde el repositorio, pero en este caso se crea un árbol de directorios limpio sin los metadatos de control de versiones presentes en la copia de trabajo.

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

Una 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.

Una Actualización integra los cambios que han sido hechos en el repositorio (por ejemplo por otras personas) en la copia de trabajo local.

Repositorios locales y repositorios remotos. Haz clic para ampliar la imagen.
Fuente propia

El objetivo básico perseguido pon un Sistema de Control de Versiones (VCS) es conseguir que varios desarrolladores trabajen simultáneamente, sin confllictos y vayan guardando cada versión obtenida, registrando cuándo se grabó, quién lo ejecutó, qué cambios se hicieron respecto a versiones anteriores, por qué se realizaron etc., es decir mantener mediante una gestión de archivos y directorios un histórico del proyecto o programa elaborado que permita incluso recuperar versiones anteriores del mismo.

Para conseguir este objetivo este software dispone de funcionalidades específicas en cada uno de los diferentes programas (Git, Subversión, Team Foundation Server, etc.) que desarrollan a través de distintas órdenes o comandos. En este punto no entraremos en diferentes programas pero si estableceremos con carácter general una serie de operaciones comunes o básicas que deben ejecutar todos ellos.

Todos ellos usan un mecanismo de almacenamiento de los datos y la información asociada (metadatos). Esta base de datos o “almacén” se llama repositorio. Las operaciones comunes que hemos comentado se producen en torno a él, introduciendo o sacando infomación del mismo. 

Cada usuario tiene una copia de ese repositorio (repositorio local) que digamos sirve de puente entre el repositorio central (repositorio remoto) y la copia local de trabajo. El flujo de información circula desde la copia local de trabajo hasta el repositorio central (remoto)  pasando por el repositorio de cada usuario (local) o bien en sentido inverso, es decir desde el repositorio remoto central al repositorio local y desde éste a la copia local de trabajo.

Algunas de las operaciones básicas con los repositorios:

Check.
Imagen en Pixabay de geralt bajo licencia CC0 Public Domain

Cuando un desarrollador  lo considera oportuno graba uno o más cambios (lista de cambios o changeset) en su repositorio estableciendo lo que se llama revisión (Check-in o Commit). Usando una terminología particular y a modo aclaratorio, es lo que podriamos llamar puntos de versión, o de restauración del proyecto, de cara a una necesidad futura de acudir a una versión anterior. Las revisiones se identifican con números o etiquetas (tags). A su vez cuando un usuario quiere empezar a trabajar manteniendo las modificaciones hechas por otro, clona el repositorio central a su propio repositorio local y también hace una copia de éste en su copia de trabajo local (Check-out). Estas operaciones en ambos sentidos se llaman integraciones. Si queremos integrar en nuestra copia de trabajo actual los cambios que han efectuado otros usuarios en el repositorio debemos usar la opción update (o Sync).

De esta forma es posible que dos o más usuarios desarrollen ramas de trabajo distintas e independientes partiendo de un mismo punto. Cuando existen conflictos por haber trabajado simultaneamente varios desarrolladores sobre un mismo fichero el propio usuario tiene que solucionarlos, aunque en algunos casos el propio sistema puede manejarlos.