Manual de GIT para Joomla! (taller de pruebas unitarias J&B Bah Nauheim)
En el J & Beyond de 2.012 se realizó un magnífico taller de Pruebas Unitarias a partir del cual salió un práctico documento técnico. En mi blog y a lo largo de 3 artículos cortos fuimos desgranando esta documentación traducida al español. Hoy al ver el renovado interes sobre este tema tras el último Joomla! Pizza, Bug & Fun, los comparto con vosotros unificados en este árticulo con la esperanza de que os resulte de utilidad.
Mark Dexter, miembro del Equipo de Liderazgo del proyecto Joomla!, facilitó a la comunidad este útil y sencillo tutorial a través de joomla.org para aquellos interesados en iniciarse en las Pruebas Unitarias para la versión 3.0 de la plataforma, tan necesarias para el proyecto.
Información General
Las siguientes tareas son básicas para los testers y desarrolladores:
- Configurar el repositorio Git en local (de solo lectura desde la rama principal).
- Se recomienda enérgicamente, tener el repositorio local actualizado con los cambios de la rama principal.
- Aplicar los parches y extraer las solicitudes:
- Opción con ramas
- Opción sin ramas
- Restaurar los archivos al estado "sin modificar"
- Trabajar con versiones anteriores
Flujo de trabajo de los testers y desarrolladores
Quienes quieran probar temas pendientes necesitan hacer lo siguiente. Estas mismas tareas se aplican a quienes quieran hacer el seguimiento y confirmar temas abiertos.
- Crear una copia de trabajo local, de la rama principal de Joomla.
- Actualizar esta copia local con los cambios realizados en el rama principal.
- Aplicar los parches propuestos (de los temas confirmados) en la rama principal, con el fin de comprobar que funcionan correctamente.
- Ser capaz de restaurar la copia local a su estado "sin modificar"
Los testers pueden querer o no, usar las ramas de Git en sus pruebas. Para una prueba individual, no es necesario crear ramas locales. Para pruebas mas complejas o pruebas múltiples, es mas conveniente crear ramas locales para cada tema. Ambos métodos se describen en este documento.
En algunos casos, es importante identificar cuando se introdujo por primera vez un error o un tema. Con Git es fácil restaurar el repositorio local a un estado anterior (por ejemplo a un punto en el pasado) y comprobar si ese tema estaba presente en dicha versión. Este proceso también se describe en este documento.
Crear un repositorio local de solo lectura
Los testers no necesitan crear un repositorio remoto en GitHub. Pueden crear un clon local de la rama principal del CMS en su máquina de pruebas. Este clon les permitirá seguir fácilmente los cambios realizados en la rama principal del CMS.
Los pasos para este proceso se muestran a continuación, en primer lugar con el interfaz-linea de comando (CLI: command-line-interface) para Git y en segundo lugar con Eclipse y eGit.
Comando CLI
Navegue a la carpeta raíz de su proyecto (por ejemplo: c:\xampp\htdocs\joomla-cms). Introduzca el comando:
git clone git :/ / github.com / joomla / joomla-cms.git
El sistema trabajará unos minutos, haciendo la copia completa del repositorio remoto a su sistema local. Cuando termine, tendrá una copia local del repositorio del CMS Joomla en el directorio actual, junto con un repositorio Git (en el subdirectorio .Git). Tenga en cuenta que esta URL apunta al proyecto joomlacms en GitHub. Este proyecto se convierte en el origen remoto para el repositorio Git local. Por ejemplo, el comando git remote-v listará ahora lo siguiente:
git remote -v
origin git://github.com/joomla/joomla-cms.git (fetch)
origin git://github.com/joomla/joomla-cms.git (push)
Comandos Eclipse
Clone el repositorio joomla-cms utilizando la URL de solo lectura. En la vista de repositorios, haga click en el botón: "Clone a Git Repository and add to this View" (Clonar un repositorio Git y agregar a esta vista).
Seleccione URI y haga click en “Siguiente”. Aparecerá la siguiente pantalla:
Introduzca la URI git://github.com/joomla/joomla-cms.git, como se muestra en la imagen superior. A continuación, haga click en “siguiente” para ver la siguiente pantalla.
Se pondrán por defecto todas las ramas seleccionadas. Mantenga este valor predeterminado y haga click en “siguiente” para mostrar la siguiente pantalla.
Haga click en “browse” (“examinar”) y navegue hasta el directorio raíz del proyecto, deseado (por ejemplo: c:\xampp\htdocs\joomla_development\joomla-cms). A continuación haga click en “finalizar”. En Eclipse, cree un nuevo proyecto PHP en la misma carpeta. Esto hará aparecer una alerta de que ya existen archivos en esta carpeta (lo que es correcto).
En Eclipse, haga click con el botón derecho en el proyecto y seleccione “team” (equipo) → “share” (compartir) , para compartir el proyecto. En la ventana “compartir proyecto”, seleccione Git y haga click en “siguiente”. En la ventana de configuración del repositorio Git, seleccione: "Use or create repository in parent folder of project" (Usar o crear repositorio en la carpeta principal del proyecto) y haga click en "finalizar".
Hay que tener en cuenta que esto crea una relación entre el repositorio local y el repositorio joomlacms en GitHub. Se puede ver esta relación abriendo la vista de repositorios y expandiendo el árbol, como se muestra a continuación.
Interface - Línea de Comando (CLI)
Asegúrese de que se encuentra en la rama principal de su repositorio local con este comando:
git checkout master
Extraiga los cambios del origen (joomla-cms):
git pull origin
Si hubiese algún cambio, estos se mostrarán. De lo contrario, mostrará el siguiente mensaje: "already up to date" ("al día").
Compruebe su estado, introduciendo: git status. La pantalla debería mostrar:
$ git status
# On branch master
nothing to commit (working directory clean)
Eclipse
Asegúrese de que se encuentra en la rama principal: Team → Switch to → master (equipo → cambiar a → principal). Si ya se encuentra en la rama principal , esta se pondrá en gris.
Extraiga los cambios del origen. Haga click con el botón derecho en el proyecto en el explorador de PHP y seleccione: Team → Pull (Equipo → Extracción).
Si hubiera cambios, se vería algo como esto:
De lo contrario, verá un mensaje indicando que todo está al día, de esta manera:
Nota importante sobre el formato de archivo del parche
Hay algún aspecto confuso al trabajar con parches entre SVN, Eclipse, Git y el interfaz-linea de comando (CLI). Esto tiene que ver con la manera en que los archivos son referenciados dentro del parche. La mayoría de los parches hechos con Eclipse y Git llevarán una "a/" y "b/" delante de los nombres de archivo. Por ejemplo, un parche estándar de Git se verá así:
diff --git a/components/com_content/controller.phpb/components/com_content/controller.php
index 53cc63a..25cee76 100644
--- a/components/com_content/controller.php
+++ b/components/com_content/controller.php
Sin embargo, los parches hechos con SVN o usando la opción “--no-prefix” en Git, van a omitir el prefijo "a /" y "/ b" y lo mostrará en el siguiente formato:
diff --git components/com_content/controller.php components/com_content/controller.php
index 53cc63a..ba2de80 100644
--- components/com_content/controller.php
+++ components/com_content/controller.php
La mayoría de los parches, tendrán el primer formato.
Es fácil aplicar parches en cualquiera de los formatos, pero los comandos son diferentes. Estos se resumen a continuación:
Aplicar parches y extraer solicitudes sin ramas
Esto puede hacerse ya sea con o sin el uso de ramas. Si se quiere trabajar en solo un parche a la vez (similar al flujo de trabajo del SVN) se puede seguir este flujo de trabajo sin ramas.
Interface - Línea de Comando (CLI)
Para aplicar un parche en formato Git: git apply <file>. Por ejemplo: git apply mypatchfile.patch.
Para aplicar un parche en formato SVN: git apply -p0 <file>. Por ejemplo: git apply -p0 mypatchfile.patch.
En este punto, los cambios de código propuestos, han sido realizados en sus archivos Joomla. Ahora se pueden probar los cambios propuestos, para ver si funcionan correctamente. Para aplicar una extracción de solicitud de GitHub, añadir “diff” al final de la URL. Esto, abrirá un fichero de parche en formato Git en su navegador. Guarde este archivo en su máquina local y utilice el comando anterior para aplicarlo.
Eclipse
Para aplicar un parche en formato Git: Team → Apply patch (equipo → aplicar parche). La ventana de especificaciones de entrada del parche, aparecerá. Se puede aplicar un parche desde un archivo o copiando el parche al portapapeles.
Haga click en “siguiente” para mostrar la ventana de “Target Resource” (recurso de destino). Seleccione el proyecto PHP para aplicar a los parches y haga click en “siguiente”. La ventana de revisión de parche aparecerá.
IMPORTANTE: Si el parche está en formato Git, ajuste "Ignore leading path elements" (“ignorar los principales elementos de la ruta”) a 1. Esto no es necesario si el parche está en formato SVN.
En este punto, si el parche se aplica correctamente, los archivos se mostrarán con una flecha azul , como se muestra a continuación:
NOTA: Si aparece un “X” roja junto a un archivo, significa que el parche se aplicará correctamente. Compruebe el formato del archivo del parche, para asegurarse de tener la configuración correcta para este tipo. Compruebe también que no ha aplicado el parche aún.
Aplicar parches y extraer solicitudes usando ramas
En muchos casos, puede ser mas fácil crear una rama de Git para cada tema en el que se está trabajando. De esta manera, se puede trabajar en varias cosas a la vez, manteniendo los cambios en el código, separados. Crear ramas en Git es muy sencillo. Este es el flujo a seguir para la aplicación de parches usando ramas.
Interface - Línea de Comando (CLI)
Crear una nueva rama: git branch issue-123 ( esto crea una nueva rama llamada tema-123) Aplicar el parche como se ha explicado con anterioridad. Validar los cambios de código en la rama: commit-a. Tras esto, Git abrirá el editor elegido en la instalación de Git.
Introduzca el mensaje de confirmación en la primera linea del editor, guarde y salga. ( Si no está familiarizado con el editor, puede cambiar el editor o usar Eclipse, el cual se salta este paso en su proceso). El mensaje de confirmación debe ser algo corto que te diga lo que has hecho, por ejemplo: “aplicado el parche 123.parche”.
En este punto, la rama contiene la versión modificada de los archivos Joomla para poder probar. Puede volver fácilmente a los archivos originales con el siguiente comando: git checkout master.
Para volver de nuevo a la versión modificada, utilice el comando: git checkout issue-123.
Eclipse
Crear una nueva rama: “Team”-> “Switch to”-> “New branch” (equipo → cambiar a → nueva rama). La ventana de creación de nueva rama, aparecerá.
Introduzca el nombre de la rama y haga click en “finalizar”. Aplicar el parche como se ha explicado con anterioridad.
Validar el cambio de código: “Team”->“Commit”. La ventana de validación se mostrará. Introduzca el mensaje de confirmación como se muestra en el siguiente ejemplo:
En este punto, puede revisar los cambios realizados en el código o simplemente pulsar en “commit” y validar los cambios.
Para volver a la rama original o cualquier otra, vuelva a utilizar: “Team”->”Switch To” y seleccione la original o la rama deseada.
Restaurar a estado "no modificado" sin ramas
Si no está usando ramas, cuando haya terminado de probar un tema, tendrá que restaurar sus programas al estado original “no modificado”. Tenga en cuenta que esto no es necesario si está utilizando ramas.
Interface - Línea de Comando (CLI)
Utilice este comando para deshacer los cambios en los archivos: git reset –hard
Utilice este comando para eliminar cualquier archivo añadido por el parche: git clean -f
Ejecute el comando: git status y asegúrese que devuelve “nothing to commit (working directory clean)” (“nada que validar(directorio de trabajo limpio)).
Eclipse
Utilice este comando para deshacer los cambios en los archivos: Team->Reset para mostrar la ventana de reinicio. Seleccione “hard” para el tipo de reinicio y haga click en “reset”.
Para eliminar cualquier archivo añadido por el parche, simplemente navegue a los archivos y elimínelos.
Restaurar a estado "no modificado" con ramas
Si utiliza ramas, es mucho mas fácil volver a los programas “no modificados”. Solo debe cambiar a la rama principal. Una vez haya terminado con un tema, probablemente quiera eliminar la rama creada. Estos son los comandos para ello:
Interface - Línea de Comando (CLI)
Cambiar de nuevo a la rama principal: git checkout master
Eliminar la rama deseada: git branch -D issue-123 (donde “issue-123” es el nombre de la rama)
Eclipse
Cambiar de nuevo a la rama principal: Team->Switch to->master (equipo → cambiar a → original)
Eliminar la rama deseada: Team->Advanced->Delete Branch (equipo → avanzado → eliminar rama) y selecciona la rama que desee eliminar.
Pruebas de versiones antiguas de la rama principal
A veces es útil averiguar que commit (validación) podría haber introducido un nuevo tema. Con Git es sencillo restaurar el código base en cualquier punto en el tiempo y luego probar si ese tema estaba presente o no.
Ya que esta tarea es mucho mas fácil de hacer con Eclipse, es lo que se detalla en este documento.
Abrir la vista de histórico: Team->Show in History (equipo → mostrar en histórico). Esto mostrará una vista similar a esta:
Esta vista muestra todas las validaciones al repositorio CMS.
Para restaurar los archivos locales a un momento anterior, haga click con el botón derecho en la linea deseada, del histórico. Ahora podrá probar esta versión.
Para cambiar de versión, repita este proceso. Para volver a la rama principal (la versión mas reciente)
haga: Team->Switch to->Master (equipo → cambiar a → original).
Sobre el autor
By accepting you will be accessing a service provided by a third-party external to https://magazine.joomla.org/
Comentarios