Introducción
Git es un sistema distribuido de código abierto y gratuito para control de versiones y Oracle SQL Developer proporciona una interfaz que permite a los desarrolladores trabajar con repositorios Git. En este artículo, voy a mostrar cómo utilizar SQL Developer para lograr una interacción básica con un repositorio GitHub (Un servicio de hosting basado en la web para proyectos de desarrollo de software que utiliza el sistema de control de versiones Git). El artículo supone que el lector tiene un conocimiento básico acerca de control de versiones y Git.
Creación de un repositorio gratuito en GitHub
Lo primero que debemos hacer es obtener una cuenta en GitHub. Se puede omitir este paso si la cuenta ya ha sido creada previamente. Una cuenta en GitHub nos da acceso a repositorios públicos que se pueden clonar; pero considero apropiado el tener un repositorio propio, ya que de esa manera tenemos control total del mismo, lo que nos permite probar la interfaz disponible en SQL Developer sin temor a “dañar” algo. Una vez que tenemos una cuenta, podemos hacer clic en el botón "New repository" que se muestra en la Figura 1.
Figura 1
Entonces aparece una pantalla similar a la que se muestra en la Figura 2, donde tenemos que introducir el nombre del repositorio que vamos a crear, decidir si el repositorio va a ser público o privado (hay que pagar por ello), si deseamos inicializar el repositorio con un README y, finalmente, hacer clic en el botón "Create repository".
Figura 2
Una vez que completamos el proceso de creación, deberíamos encontrarnos en la página principal de nuestro repositorio que debe lucir en forma similar a la Figura 3.
Figura 3
La página principal del repositorio muestra un elemento llamado “HTTPS clone URL”, cuyo contenido vamos a necesitar cuando intentemos establecer una conexión a GitHub desde SQL Developer. La flecha roja en la Figura-3 nos indica su ubicación.
Clonando un repositorio GitHub
Si deseamos obtener una copia de un repositorio GitHub, tenemos que "clonarlo". Para clonar un repositorio debemos ir al menú principal de SQL Developer y hacer clic en Team -> Git -> Clone ... para abrir el asistente "Clone from Git". Este asistente tiene 3 partes importantes excluyendo las pantallas de bienvenida y de resumen. La Figura 4 muestra la primera parte referente al "Remote Repository”. En esta sección debemos especificar los detalles que se necesitan para establecer una conexión con el repositorio GitHub. Aquí debemos proporcionar el nombre del repositorio, la dirección “HTTPS clone URL” que está disponible en la página principal del repositorio, el nombre de usuario y contraseña. Luego hacemos clic en el botón "Next" para intentar conectar con el repositorio remoto y avanzar a la siguiente sección.
Figura 4
Si la conexión al repositorio fue exitosa, el asistente nos lleva a la segunda parte referente a la “Remote Branch” como se muestra en la figura 5. La rama "Master" se crea de forma predeterminada en cada nuevo repositorio y en este caso es la única que podemos clonar. Aquí tomamos los valores predeterminados y hademos clic en el botón "Next" para avanzar a la siguiente parte.
Figura 5
La tercera parte corresponde a "Destination" como nos muestra la Figura 6. Aquí debemos especificar la ubicación para almacenar el repositorio Git local. Tenemos que proporcionar la ruta de acceso para el repositorio local, el nombre del mismo y la rama. Luego hacemos clic en el botón "Next" para ver un resumen de las opciones que hemos elegido y finalmente hacemos clic en el botón "Finish" para completar la clonación del repositorio.
Figura 6
¿Cómo podemos comprobar si la clonación del repositorio se realizó? Simplemente debemos ir a la ruta que especificamos para el almacenamiento de nuestro repositorio local y comprobamos que contenga la misma estructura y elementos disponibles en el repositorio remoto (GitHub). En este caso la Figura 7 nos muestra que todo ha sido copiado a nuestro repositorio local.
Figura 7
Actualizando el repositorio local con cambios hechos en el repositorio GitHub
Existen al menos dos formas de actualizar el repositorio local con los cambios realizados por otros desarrolladores. Una manera es utilizando la operación de "checkout". Cuando se extraen archivos desde el repositorio Git remoto, se lo puede hacer a partir de una revisión y rama específica. Opcionalmente, se puede elegir entre las etiquetas existentes y extraer archivos que pertenecen a una revisión etiquetada. Otra manera es la que vamos a utilizar en este artículo y que hace uso de la operación "fetch". La operación fetch toma archivos que han sido modificados en el repositorio remoto y los copia al sistema local pero no modifica ninguna de las ramas existentes en el repositorio local. En ese momento, el desarrollador puede visualizar las diferencias entre las versiones y decidir si desea incluir los cambios en el repositorio local. Para demostrar la operación fetch, vamos a utilizar GitHub para crear un archivo llamado sp_test_git.pls y posteriormente agregarlo al repositorio remoto. Se pueden crear archivos haciendo clic en el icono de señalado por la flecha roja de Figura 8.
Figura 8
La Figura 9 muestra el contenido del archivo que no es más que un procedimiento PL/SQL que imprime un mensaje.
Figura 9
En este punto, el repositorio remoto y el repositorio local ya no se encuentran sincronizados. Supongamos que debemos empezar a trabajar en el proyecto y por lo tanto tenemos que asegurarnos de incorporar los cambios realizados por otros desarrolladores. En primer lugar tenemos que abrir la ventana “Versions”. Para ello, vamos al menú principal de SQL Developer y hacemos clic en Team -> Versions. La ventana debería mostrar un contenido similar a la Figura 10.
Figura 10
Ahora procedemos hasta la rama "Local" y hacemos clic en "Master". Luego vamos al menú principal de SQL Developer y hacemos clic en Team -> Git -> Fetch para abrir el asistente "Fetch from Git". Aquí introducimos los detalles del repositorio, seleccionamos la rama y completamos la operación. Para poder ver los cambios debemos abrir la ventana “Branch Compare” yendo al menú principal y haciendo clic en Team -> Git -> Branch Compare. Lo que se ve debe ser similar a la Figura 11.
Figura 11
La ventana “Branch Compare” nos indica que el archivo sp_test_git.pls ha sido copiado a nuestro sistema local pero aún no es parte del repositorio. Si hacemos clic derecho sobre el nombre de este archivo y elegimos la opción “Compare”, podemos ver que se despliega una ventana similar a la que se muestra en la Figura 12. En dicha ventana el panel de la izquierda muestra el contenido del archivo que ha sido copiado y el panel de la derecha muestra el contenido del mismo archivo en el repositorio local. En este caso, el panel de la derecha está vacío porque se trata de un archivo nuevo que aún no existe en el repositorio local.
Figura 12
Podemos aceptar los cambios e incorporarlos al repositorio local si vamos a la ventana “Branch Compare”, hacemos clic derecho sobre el nombre del archivo y seleccionamos la opción “Merge”.Veremos que se abre una ventana similar a la de la Figura 13 donde elegimos la rama en la que se van a incorporar los cambios. Luego hacemos clic en el botón “Ok" para completar la operación.
Figura 13
Podemos confirmar que el proceso ha sido exitoso si vamos a la ruta que especificamos para almacenar nuestro repositorio local y el archivo sp_test_git.pls se encuentra ahí. Deberíamos ver algo similar a la Figura 14.
Figura 14
Actualizando el repositorio GitHub con cambios hechos en el repositorio local
Lo que vamos a hacer aquí es modificar el archivo sp_test_git.pls en el repositorio local y luego vamos a incorporar dichos cambios al repositorio remoto (GitHub). En primer lugar procedemos a abrir el archivo sp_test_git.pls utilizando SQL Developer. Luego añadimos otra línea DBMS_OUTPUT en procedimiento PL/SQL y guardamos los cambios. Una vez que modificamos el archivo, la ventana “Pending Changes (Git)” se actualiza para reflejar el cambio y los iconos en la barra de herramientas quedan habilitados como se muestra en la Figura 15.
Figura 15
La ventana “Pending Changes (Git)” nos permite añadir comentarios relacionados con el cambio que estamos haciendo y también nos permite agregar el archivo a un área temporal conocida como “Staging Area” cuando hacemos clic en el botón "Add"ubicado en la barra de herramientas. Aquí podemos observar como el estado del archivo cambia de "Modified Not Staged" a "Modified Staged" tal como se muestra en la Figura 16.
Figura 16
¿Qué debemos hacer si queremos comparar las versiones antes de incorporar los cambios al repositorio local? Solamente tenemos que hacer clic en el botón “Compare with Previous Version” ubicado en la ventana “Pending Changes (Git)” para ver algo similar a los que se muestra en la Figura 17.
Figura 17
El panel del lado izquierdo muestra la versión del archivo almacenada en el repositorio local y el panel de la derecha muestra la versión que se encuentra en la “Staging Area”. Las diferencias se encuentran resaltadas para ayudar en su identificación. El siguiente paso consiste en incorporar los cambios al repositorio local. Para lograrlo, debemos hacer clic en el botón “Commit” ubicado en la ventana “Pending Changes (Git)” para que nos lleve a la ventana “Commit” que se muestra en la Figura 18. Aquí podemos aceptar los valores por defecto y hacemos clic en el botón “OK” para modificar el repositorio local.
Figura 18
Una vez que los cambios se han aplicado al repositorio local, la ventana “Branch Compare” nos informa que los repositorios local y remoto ya no se encuentran sincronizados. Por lo tanto deberíamos ver algo similar a lo que se muestra en la Figura 19.
Figura 19
El último paso consiste en sincronizar los repositorios remoto y local al incorporar los cambios a GitHub utilizando la operación “push”. Para lograrlo vamos al menú principal de SQL Developer y hacemos clic en Team -> Git -> Push para abrir el asistente "Push to Git" donde debemos introducir la URL del repositorio remoto, el nombre de usuario y contraseña. Después de completar la operación “push”, podemos ir a GitHub para confirmar se han aplicado los cambios. Deberíamos ver algo similar a la Figura 20.
Figura 20
Resumen
Un sistema de control de versiones es uno de los componentes más importantes de cualquier proyecto de desarrollo de software. Oracle SQL Developer reconoce su importancia y proporciona soporte integrado para CVS, Subversion y Git, dando a los desarrolladores la flexibilidad suficiente para ejecutar operaciones de control de versiones en repositorios remotos y locales. En este artículo se ha intentado explicar cómo empezar a utilizar esta valiosa funcionalidad mediante la ejecución de operaciones básicas para interactuar con un servicio web que utiliza el sistema de control de versiones Git.
Galo Balda es un Ingeniero de Bases de Datos y Desarrollador de Software que trabaja para el Estado de Texas donde se especializa en el diseño y rendimiento de las aplicaciones que proveen servicios a programas como Medicaid, Medicare, CHIP, Medical Transportation. Galo posee varias certificaciones de Oracle y ha presentado en conferencias como RMOUG Training Days y ODTUG Kscope. Galo posee un Blog en español y otro en inglés.