Usando Xojo con GitHub

A continuación encontrarás traducido al Castellano el artículo escrito por Paul Lefebvre y publicado originalmente en el Blog Oficial de Xojo.

Ahora que Xojo Lite incluye soporte para guardar los proyectos en un formato compatible con los sistemas de control de versiones, parece un buen momento para revisitar el modo en el que puedes utilizar Xojo con GitHub, el popular servicio de hosting en línea para Git.

¿Qué son Git y GigHub?

Git es un sistema de control de versiones de código abierto, también conocido como sistema de control de versiones para código fuente y que fue creado por Linus Torvalds en 2005; es sin duda el sistema de control de versiones más popular, sustituyendo así a Subversion como tal.

GitHub es un servicio de hosting en línea para Git, propiedad de Microsoft. GitHub proporciona características adicionales sobre las de simplementer alojar repositorios de Git, pero en este artículo sólo nos centraremos en sus capacidades de hospedaje para Git. El uso de GitHub es gratuito tanto en los casos de repositorios públicos como privados.

En esencia, un repositorio es el lugar en el que se almacena un proyecto. Los repositorios públicos suponen un gran modo de compartir proyectos de código abierto. Otros pueden verlos y descargar el código fuente. Los repositorios privados sólo son visibles para ti y son geniales para tus propios proyectos internos.

Git es un sistema de control de versiones distribuido, lo que significa que el código fuente puede versionarse localmente y en el servidor, sincronizándolos sólo cuando sea necesario. Sin embargo, y para hacerlo simple, lo más frecuente es mantener ambos sincronizados. Los anteriores sistemas de control de versiones como Subversion estaban basados en un servidor, y las versiones sólo se mantenían en el servidor. Un sistema de control de versiones distribuido es ligeramente más complejo, pero tiene la ventaja de que resulte más sencillo trabajar cuando no existe conexión a Internet.

Un sistema de control de versiones registra los cambios realizados sobre archivos de texto (aunque no de forma exclusiva sobre estos), algo que es increíblemente útil cuando se trata de código fuente. El hecho de registrar los cambios es una tarea muy común y necesaria cuando se programa. Es probable que hayas visto a muchos guardar sus proyectos como MyProyecto1, MyProyecto2, MyProyectoNuevaVersion, etc. Esta es una forma rudimentaria a la hora de intentar asegurarse de que no pierdes cambios cuando actualizas tu código. Con el control de versiones y el formato de archivo de Xojo compatible con el control de versiones, tendrás en tu mano una técnica mucho más flexible.

Cuando guardas tu proyecto utilizando el formato de archivo de Xojo compatible con el control de versiones (denominado Xojo Project), cada elemento del proyecto se guarda en su propio archivo, y el contenido de cada uno de ellos es texto plano – lo que significa que puedes verlos utilizando un editor de textos, si así lo deseas.

Puede que estés pensando: “Sólo desarrollo yo; no necesito de esta complejidad adicional.” Pero los sistemas de control de versiones no son sólo para equipos compuestos por varios desarrolladores. Seguro, el control de versiones es un modo genial a la hora de asegurarse de que diferentes miembros del equipo no realicen diferentes cambios sobre el mismo código. Pero el registro de los cambios también resulta útil para todos, incluso si eres el único desarrollador de tu equipo; de modo que podrás revisar los cambios previos, y “deshacer” los cambios en el caso de que no estén funcionando como esperabas, como si se tratase de un salvavidas. Así, se encarga de eliminar el miedo a “romper cosas” en tu flujo de trabajo. Además, el hecho de que tu código fuente esté en un servidor remoto (GitHub) también puede resultar útil como copia de seguridad para tu código fuente.

Un ejemplo rápido

Para hacerte una idea sobre cómo funciona, pongamos por caso un simple archivo de texto que existe en Git: ReadMe.txt

Inicialmente sólo contiene este texto:

¡Hola!

Descargas (Pull) el archivo a tu ordenador (definiré los términos de Git en breve) para trabajar en él. Tras abrir el archivo en un editor de textos, cambias el contenido y lo guardas:

¡Hola, Xojo!

Ahora, el archivo de tu ordenador contiene dicho texto. Esto se denomina copia de trabajo (Working Copy). El archivo en el repositorio aun contiene el texto “¡Hola!”. Ahora puedes hacer un par de cosas útiles.

Puedes solicitar ver las diferencias entre el archivo en el repositorio y el que tienes en la copia de trabajo. Al hacerlo, la mayoría de las herramientas resaltarán la línea que ha cambiado, mostrando los contenidos del repositorio a la izquierda y los contenidos de la copia de trabajo a la derecha. Esta es una forma magnífica de revisar los cambios realizados en el código.

La otra coas que puedes hacer es enviar el cambio al repositorio (Commit). Esta acción añade el archivo al repositorio y lo convierte en la última versión. En Git podrás ver que este archivo tiene dos versiones, y podrás ver el contenido del archivo para cada una de las versiones.

Estas dos cosas significan que nunca volverás a perder tu trabajo. Cada vez que realices un cambio en tu código y que quieras conservarlo como una nueva versión, sólo has de enviarlo (Commit) al repositorio. Probablemente no querrás enviar cada mínimo cambio realizado, ya que sería demasiado granular y sería difícil de gestionar, pero significa que puedes realizar con seguridad múltiples cambios de calado sobre alguna característica y aun así ser capaz de volver y revisar como era el código anteriormente.

La otra cosa útil que puedes hacer es revertir los cambios. Si, tras guardar el archivo con “¡Hola, Xojo!” te das cuenta de que ha sido un error, puedes volver atrás recuperando la versión anterior; para ello sólo tendrás que elegir la opción “Revert” sobre dicho archivo. Esta operación descarta todos los cambios realizados en la copia de trabajo local y recupera la versión más reciente desde el repositorio.

Soy consciente de que, inicialmente, todo esto puede resultar diferente y confuso, pero una vez que lo hagas sobre un par de proyectos pequeños te harás rápidamente con los mandos y nunca querrás volver atrás para utilizar MyProject1, MyProject2, etc, de nuevo.

Terminología

Repositorio: Este es, en esencia, el lugar en el que se almacenan un grupo de archivos que, para nuestro propósito, será un proyecto de Xojo guardado en el formato de archivo compatible con el control de versiones (Xojo Project).

Clone: Copia el repositorio a tu ordenador, de modo que puedes trabajar con él.

Fetch: Actualiza el repositorio local con cualquier cambio almacenado en el servidor.

Pull: Similar a Fetch, excepto que también copia los cambios en la copia de trabajo.

Commit: Añade el archivo modificado al repositorio como nueva versión.

Push: Envía el archivo sobre el que se ha hecho “Commit” al servidor (GitHub). A menudo esto se realiza en un solo paso: Commit and Push.

Working Copy: La copia local del repositorio y del archivo.

Uso General de GitHub

El flujo de trabajo general que usarás con Xojo será:

Crea un repositorio en GitHub para el proyecto.
Haz un Pull del mismo a una carpeta de tu ordenador.
Crea un nuevo proyecto Xojo.
Guárdalo en formato Xojo Project (texto) sobre la carpeta anterior.
Haz un “Commit and Push” del proyecto a GitHub.
Realiza cambios en el proyecto Xojo.
Haz un “Commit and Push” a GitHub a medida que lo consideres.

Crea una cuenta en GitHub

En el caso de que aun no tengas una cuenta en GitHub, tendrás que crear una. Dirígete a la página en cuestión para iniciar el proceso:

Crear un Repositorio

Ahora que ya tienes una cuenta en GitHub, querrás dirigirte a tu página de inicio de GitHub y hacer clic en el botón “New Repository”.

Tal y como se ha mencionado anteriormente, un repositorio es en esencia el lugar en el que se almacenará tu proyecto. Por lo general querrás crear un repositorio independiente para cada uno de tus proyectos. Este es el aspecto que tiene el formulario para crear un nuevo repositorio:

Para los proyectos de código abierto querrás asegurarte de seleccionar “Public”, ya que no sería realmente de código abierto si no fuese público. Para todos los repositorios públicos, asegúrate de utilizar un “nombre de repositorio” que sea interesante e incluye siempre una descripción. Selecciona “Private” para los proyectos internos.

Personalmente siempre agrego un archivo “README”, opción que añade un archivo README vacío en el repositorio. Podrás actualizarlo luego, pero es donde incluirás una breve descripción del proyecto y de cómo utilizarlo (utilizando Markdown). El README se mostrará por omisión cuando te dirijas al repositorio utilizando un navegador Web.

También deberías seleccionar “Xojo” para la plantilla gitignore (haz clicl en el menú emergente y teclea “xojo”). Esto identifica el proyecto como uno en el que se utiliza el lenguaje de programación Xojo, lo cual facilita las búsquedas y también marca el archivo “uistate” (que contiene ajustes específicos del usuario para la interfaz de usuario, tales como posición y tamaños de ventana) de modo que no se incluyan como parte del proyecto.

Por último se encuentra la licencia. Para la mayoría de los proyectos de código abierto, te recomiendo utilizar la licencia MIT, la cual permite esencialmente que cualquiera pueda utilizar tu código del modo que quieran. Para los proyectos privados, puedes dejarlo como “None”.

Haz clic en el botón Create Repository para crear el repositorio.

Clona el Repositorio a tu ordenador

Con el repositorio ya creado, puedes verlo en el sitio web de GitHub correspondiente a tu cuenta:

A partir de este punto, podrás ver los archivos en el repositorio junto con otra información.

Ya estás listo para “clonar” el repositorio a tu ordenador. Esta acción copia los archivos del repositorio a una carpeta en tu ordenador, de modo que puedas modificar sus archivos. Por supuesto, los únicos archivos del repositorio serán LICENSE y el archivo README.md vacío, pero aún así es necesario hacer un Clone para que puedas crear la carpeta en la que añadirás tu código Xojo.

Para hacer el clonado, querrás utilizar una aplicación cliente de Git. Hay muchas entre las que elegir, pero dos que son gratuitas son la oficial de GitHub Desktop y SourceTree de Atlassian. GitHub Desktop es más sencilla, de modo que es la que mostraré aquí.

Descarga GitHub Desktop: https://desktop.github.com

Ejecuta GitHub Desktop y haz clic en “Sign into GitHub.com”.

En la página Configure Git, introduce el nombre y el email que quieras utilizar para identificar tus commits.

Haz clic en Finish en la siguiente página para acceder a la pantalla principal donde tendrás la opción de crear nuevos repositorios o bien clonar un repositorio. Dado que ya has creado un repositorio en línea en la anterior sección, querrás seleccionar “Clone Repository” (también puedes seleccionarlo en el menú File). En este listado, selecciona el repositorio que has creado anteriormente, elige la ubicación de la carpeta local (Choose…) y haz clic en Clone.

Ahora tendrás una carpeta en tu disco donde podrás añadir tu proyecto Xojo. Este es el aspecto que tendrá el repositorio en GitHub Desktop:

Nota: Si estás utilizando otro cliente de Git, tendrás que elegir la opción equivalente a “Clonar un repositorio desde el URL indicado”, e indicar el URL mostrado en el botón “Clone or Download” de la página del repositorio.

Añade tu Código de Proyecto Xojo

Inicia Xojo y abre el proyecto que quieras para el repositorio clonado (o bien puedes crear un nuevo proyecto). Haz clic en “Save As” y asegúrate de que el Formato es “Xojo Project”; selecciona a continuación la carpeta que creaste al clonar el repositorio.

Vuelve a GitHub Desktop y ahora verás que se muestran todos los archivos de Xojo en el listado como “changed files”. (Para esta prueba he utilizado un Xojo SQLiteExample).

Ahora has de hacer un “Commit” de estos cambios. Por omisión estarán todos seleccionados en GitHub Desktop, de modo que puedes introducir un breve resumen y descripción (para el primer commit generalmente se utiliza “Commit Inicial”, pero yo he utilizado “Commit Xojo Inicial”) y haz clic en el botón “Commit to main”.

Cada vez que hagas un commit querrás asegurarte de escribir un comentario y descripción claros sobre los cambios. Esta información resultará luego de ayuda cuando estés revisando commits previos.

Esta operación ha marcado los archivos como “commited” en tu repositorio local, lo cual es necesario antes de que envíes (Push) los cambios al repositorio en línea. Por lo general, querrás hacer commit de los cambios cuando hayas realizado cambios que quieras trazar. No tienes por qué enviar los cambios de inmediato al servidor (repositorio en línea) cada vez; sin embargo, por lo general la mayoría lo hace porque resulta más sencillo. Algunos clientes de Git ofrecen con frecuencia un botón o comando que se encargan de hacer el Commit y el Push en un único paso.

Para este commit inicial querrás hacer un push del commit al servidor, de modo que haz clic en el botón de la barra de herramientas etiquetado “Push origin”. Esto envía el commit al origen, que es el repositorio de GitHub en este caso.

Si vuelves ahora al repositorio en línea de GitHub y refrescas la página verás que ahora aparecen los nuevos archivos enviados:

Compartir tu Proyecto público

Si has creado un repositorio público entonces estará disponible ahora en GitHub para cualquiera que lo quiera usar. La gente puede encontrarlo mediante búsquedas o bien puedes compartir el URL (quizá en el Foro de Xojo).

Puesto que he publicado un proyecto público, cualquiera puede usarlo. Esto significa que pueden clonarlo y enviar cambios a tu proyecto como “pull requests”. Un “pull request” es un cambio realizado por un usuario y que querría ver aplicado en tu proyecto. Debido a que es tu proyecto, otras personas no pueden realizar cambios directamente en él salvo que los añadas como colaboradores. Sin embargo, puedes revisar estas solicitudes de cambios (Pull Request) y hace un pull y merge de dichos cambios en tu proyecto si así lo deseas. O bien puedes rechazar el pull request – depende de ti, dado que es tu proyecto.

Cambiar y Actualizar tu Proyecto

Probablemente seguirás cambiando tu proyecto para corregir bugs y añadir características. Cada cambio realizado se mostrará en GitHub Desktop, donde podrás hacer un commit de los mismos, y después hacer un push al servidor.

Como ejemplo, vuelve a Xojo y haz un cambio en el proyecto. He añadido algunos comentarios al método AddTeamRow. Tras guardar, los cambios estarán ahora visibles en GitHub Desktop:

Ahora puedes ver el único archivo que se ha cambiado, SQLiteWindow, y los cambios (o diff) se muestra en el visor. Aquí puedes ver los cambios resaltados como líneas en azul en el margen. El primer cambio muestra que la línea 386 se ha eliminado y sustituido, indicando que se ha añadido como cambio “Please”.

Los dos cambios siguientes indican que se han añadido nuevas líneas al código.

Siempre es bueno revisar el código como este antes de hacer el commit para asegurarte de que los cambios son los que esperas.

Puedes hacer un Commit de este cambios (añade siempre una descripción y un resumen, de modo que sepas los motivos del cambio), y haz a continuación un Push al servidor (Push origin).

Descartar Cambios

Digamos que has realizado cambios en el proyecto Xojo pero te das cuenta de que realmente has empeorado las cosas, y quieres volver al estado anterior del código. Por ejemplo, pongamos por caso que he borrado accidentalmente un fragmento de código en el método ShowData y he guardado el proyecto. En GitHub Desktop, se vería así:

Puedes ver una gran área de color rojo indicando que el código se ha eliminado.

Para descartar este cambio, puede hacer clic derecho en SQLiteWindow en GitHub Desktop y seleccionar “Discard Changes”. Dicha acción abrirá un diálogo de confirmación, y tras hace clic en Discard Changes, restaurará el archivo a su versión anterior correspondiente a la versión del archivo que se envió por última vez al repositorio.

Tras hacer esto, tendrás que cerrar el proyecto en Xojo y volver a abrirlo de modo que actualice las estructuras internas del proyecto para reflejar los cambios descartados. Tras ello, puedes volver al método ShowData y comprobar que el código ha sido restaurado.

Esta capacidad es uno de los grandes motivos por los cuales el control de versiones resulta increíblemente útil incluso si eres el único desarrollador que trabaja en un proyecto.

Usar o Clonar otros Repositorios

No olvides de que también puedes usar los repositorios públicos de otros desarrolladores. Para ello, sólo has de hacer clic en el botón “Clone or Download” de la página del repositorio.

Para un uso simplificado, en el que sólo quieres coger la versión actual del repositorio porque no tienes previsto cambiar nada, puedes hacer clic en el botón Download ZIP. Una vez descargado, descomprime el archivo y abre el proyecto en Xojo, donde podrás usarlo o bien Copiarlo y Pegarlo en tus propios proyectos (por supuesto, revisa el acuerdo de licencia antes de usarlo en tus proyectos).

Querrás clonar un proyecto cuando quieras gestionarlo usando GitHub Desktop (o bien tu cliente preferido para GitHub). Esto te permite hacer fetch/pull de las actualizaciones desde el repositorio en línea y también te permite realizar tus propios cambios y enviarlos al servidor donde el propietario del repositorio los recibirá como solicitudes de modificaciones, tal y como se ha descrito anteriormente.

Cambiar el Formato de Proyecto por omisión

Es probable que encuentres de utilidad cambiar el formato de proyecto utilizado por omisión para que sea el formato compatible con el control de versiones. Así siempre estará seleccionado cuando guardes los proyectos. Puedes cambiarlo en la sección General Settings de las preferencias de Xojo:

Consejo Pro: Cuando guardes un proyecto por primera vez en el formato de control de versiones, siempre es buena idea guardarlo en una carpeta recién creada. Esto garantiza que todos los archivos estarán contenidos en una única ubicación y que no se sobreescribirá nada de forma accidental que pudiese encontrarse ya en la carpeta.

El Camino de Git

Si has creado proyectos Xojo en repositorios públicos de GitHub, ¡asegúrate de compartirlos en el Foro!

Este artículo sólo rasca la superficie de lo que puede hacer GitHub y también toca ligeramente las capacidades de Git y el concepto del control de versiones en general. Si quieres utilizar Git para el control de versiones, pero prefieres una alternativa a GitHub entonces puedes echar un vistazo a BitBucket de Atlassian, quien también ofrece hospedaje para proyectos GitHub, tanto públicos como privados.

Aprende más en la Documentación de Xojo.

Paul aprendió a programar en BASIC cuando tenía 13 años, y desde entonces ha programado en más languages de los que puede recordar, siendo Xojo su evidente favorito. Cuando no está trabajando en Xojo, puedes encontrarle hablando sobre computadores retro en Goto 10 y en Mastodon @lefebvre@hachyderm.io.