Sourcetree versión 2.7.6

Sourcetree es una herramienta muy útil para gestionar todos tus repositorios. Anteriormente había hecho hace cuatro años un tutorial sobre Source Tree.

Si bien su funcionamiento sigue siendo el mismo, han cambiado algunas cosas que merecen ser vistas. Pero antes hay que descargarlo desde Atlassian y necesitarás registrarte que además te servirá como cuenta de Bitbucket.

Una vez instalado elegimos un directorio como primer repositorio local.

Añadir o crear un repositorio local existente.

O en remoto conectaríamos una cuenta Bitbucket o Github, según nuestra preferencia para que se sincronice nuestros proyectos en remoto. O directamente clonar indicando la url del repositorio remoto.

Elegimos crear un repositorio local eligiendo el directorio y accedemos al repositorio.

Vemos que hay ficheros no preparados. Marcamos la casilla de Ficheros no preparados y automáticamente quedarán todos los ficheros preparados para después realizar el commit. También se pueden elegir individualmente los ficheros no preparados por si no queremos añadirlos todos al commit. En la parte derecha nos muestra el contenido de cada fichero.

En la parte inferior nos aparece Mensaje para Anotar que servirá como descripción del commit. Un commit es como guardar una instantánea del proyecto en ese momento, por eso es muy importante este tipo de herramientas como control de versiones.

Al dar al icono del usuario, nos preguntará nuestro nombre y correo para así identificar quién realizó el commit.

Esto solo se realizará la primera vez aunque si queremos otro usuario diferente que no sea el nuestro y también forma parte del proyecto, pulsamos sobre icono usuario y podremos tener un usuario alternativo.

Volvemos escribir la descripción y después pulsar opción Anotar.

Nos vamos al historial y podremos ver el commit realizado.

Ahora vamos a Configuración, después a la pestaña Remotos y botón Añadir.

Indicamos los datos para el repositorio remoto, con el nombre del repositorio que hayamos creado en GitHub o Bitbucket, la url y nuestro nombre de usuario.

Tendremos que darle a OK para que termine de agregarse el repositorio remoto correctamente.

Ahora vamos a Push para enviar el repositorio local al remoto. Vemos que nos aparece para marcar la rama master (después se irán teniendo más ramas). Damos OK y nos pedirá las credenciales de la cuenta GitHub/Bitbucket para el repositorio remoto.

Si comprobamos nuestro repositorio en GitHub o Bitbucket, veremos que ya está subido.

Cuando realizamos un nuevo commit desde local, Sourcetree nos avisa que una de las ramas está más avanzada que la otra, en este caso la master local frente a la master remota y nos sugiere si queremos hacer un Push para actualizar la remota. Vemos además que en la parte derecha nos muestra los cambios que hay en el fichero, resaltando en rojo lo que había antes frente a lo verde que es el cambio realizado.

 

Olvidé comentar que cuando Sourcetree nos detecta nuevos cambios para realizar un commit, si vamos al historial se nos mostrará en la gráfica por encima de los demás commit que si han sido realizados. Cambios sin un commit.

 

Lo siguiente es trabajar con una rama local nueva que llamaremos develop. Siempre se recomienda trabajar con una rama distinta a la master y será nuestra rama de desarrollo.

Al crearla podemos comprobar que estamos en ella viendo en RAMAS que tenemos marcada develop.

Realizamos cambios y después un commit. Vemos entonces que develop avanza al último commit mientras que master se queda en la anterior.

Realizamos ahora unos test (algo que veremos en un próximo tutorial) de nuestro código y tras el siguiente commit podemos ver que develop sigue avanzando.

Puede ocurrir que ahora realicemos cambios muy pequeños y queramos añadirlos al último commit guardado. En este caso se nos notifica que hay cambios sin un commit y queremos agregarlos a test.

Cuando vayamos hacer el commit, si nos fijamos en la parte derecha vemos que tenemos Opciones de la anotación… Lo que tenemos que marcar es la opción Corregir la ultima anotación y automáticamente nos marcará la anotación del ultimo commit, en este caso test, pero previamente con un mensaje de advertencia que no recomienda esta acción si ya tenemos el cambio anterior en el repositorio remoto. En el caso de no tenerlo le damos aceptar.

Una vez que hayamos hecho los test necesarios para garantizar que los avances de develop son seguros, es hora de fusionar la rama master con develop. Para ello vamos primero a RAMAS para elegir la rama master y después a la opción Integrar. Se nos mostrará la siguiente ventana donde podemos elegir en qué commit queremos fusionar, en este caso en test que es el último, para después marcar algunas de las Opciones que nos ofrece. Si estamos en una situación que no debería haber conflictos entonces con marcar la primera opción ya es suficiente.

A tener en cuenta que si eliminamos ficheros en nuestro proyecto, estos también será detectados y quedan marcados en rojo de la siguiente forma (amarillo con puntos suspensivos son ficheros modificados y con interrogante son ficheros nuevos).

Si tenemos tanto ramas locales como remotas y hacemos un commit en una local, en este caso develop, podemos ver que las ramas que no han hecho el commit aunque sean remotas, nos lo indicará.

Pero claro, eso no significa que si se hacen cambios en el repositorio remoto, estos queden reflejados en local. Para ello tendremos que hacer un Pull (la opción Recibir).

Por supuesto en los casos que hagamos Push, siempre tenemos que asegurarnos en que no habrá problemas y no entre en conflicto con una rama del cual no se desee o no se tenga que modificar en ese momento.

De esta forma iremos teniendo nuestro control de versiones de forma correcta, habituándonos a trabajar con ramas.

 

Para terminar si estamos habituados a los comandos git podemos abrir el terminal desde la opción Terminal que se encuentra en la parte superior derecha.

Ejecutando comando git podremos ver los comandos que se usan habitualmente.

Y la documentación para ver los comandos con más detalle siempre la podremos ver desde git documentation.

Magento 2 – Vista y Controlador

Detalles a tener en cuenta

Continuando con el anterior tutorial Magento 2 – Crear módulo y una vez tenemos creado el módulo, comenzamos por cargar la página siendo localhost/programas/magento2/ en mi caso y veremos lo siguiente.

Eso se debe a que el diseño del sitio web está roto y para solventarlo ejecutamos el siguiente comando desde el terminal.

bin/magento setup:static-content:deploy -f

Este comando lo debemos usar cuando ha habido cambios en ficheros CSS, JS o html, todo lo relacionado con la parte frontend. De esta forma solventaremos el problema.

 

Vamos a crear dentro de la carpeta etc, la carpeta frontend y después el fichero routes.mxl dejándolo vacío y cargamos la página.

Se nos produce un error y nos viene un identificador del log. Para verlo vamos a var > report y desde ahí veremos el log.

Nos indica que no encuentra ninguna etiqueta en el fichero xml. Lo importante de esto es saber localizar los log cuando se nos produzca algún error.

 

Continuamos con el fichero routes.xml. En Magento las rutas se divide en tres partes: frontname, controller y action.

<route id="holamundo" frontName="holamundo" >

Tanto en id como en frontName podemos poner el namespace o el nombre del módulo, por lo general se suele poner el nombre del módulo. Además frontName será la primera parte de la ruta y en este caso nuestra ruta sería:

localhost/programas/magento2/holamundo

Podemos especificar la ruta para el administrador. Para ello dentro de etc creamos la carpeta adminhtml y el fichero router.xml que será casi igual cambiando standard por admin.

 

Desarrollar el controlador

Vamos a por el controlador. Para ello creamos desde la raíz del módulo la carpeta Controller, dentro de ella la carpeta con el nombre del controlador Index y el fichero php que será la clase controlador index.php.

En namespace empezamos por el namespace Ejemplo, seguido del nombre del módulo > Controller > nombre del controlador > nombre del fichero php.
La clase Index hereda de Action que lo podemos encontrar en vendor > magento > framework > App > Action.

Y usa ResultFactory indicando el tipo RAW.

Si accedemos a vendor > magento > framework > Controller > Result > Raw.php ahí veremos el método setContens.
Para el administrador creamos dentro de Controller la carpeta Adminhtml, a su vez carpeta index y dentro index.php con algunos cambios.

Vamos al terminal y ejecutamos el siguiente comando que es necesario siempre que hagamos cambios para verlo al recargar la página.

bin/magento cache:flush

Y cargamos la página localhost/programas/magento2/holamundo.
De esta forma verificamos que el controlador funciona con la ruta especificada en el frontname de router.xml.

Y desde el panel administrador, accediendo con el usuario y contraseña vamos primero a Stories > Configuration.

Después a Advanced > Admin y desmarcamos Add Secret to URLs para que no se muestre al cargar la pagina desde el panel administrador.

Finalmente cargamos la página HolaMundo siendo administrador.

 

Y ahora la vista

Continuamos y dentro de nuestro módulo creamos la carpeta Block y en Block el fichero Hello.php donde la clase extiende de Template y un método simple que llamaremos a la vista para mostrar un texto.

Por tanto, creamos dentro del módulo las carpetas view > frontend > layout y creamos el fichero acorde a la acción del controlador. Siguiendo la ruta del proyecto, tendrá el nombre del módulo (que a su vez habíamos especificado en el id de la etiqueta route en el fichero routes.xml) seguido de guión bajo, nombre de la carpeta del controlador seguido de guión bajo y nombre del controlador. En este caso holamundo_index_index.

<?xml version="1.0"?>
<page xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" layout="1column" xsi:noNamespaceSchemaLocation="urn:magento:framework:View/Layout/etc/page_configuration.xsd">
    <body>
        <referenceContainer name="content">
            <block class="Ejemplo\HolaMundo\Block\Hello" name="holamundo_index_index" template="Ejemplo_HolaMundo::index.phtml" />
        </referenceContainer>
    </body>
</page>

Con la etiqueta page estamos indicando la estructura del diseño a una columna con layout=»1column (que puede ser diferente dependiendo de lo que queremos hacer) y la URN para la configuración del diseño de la página.
Con referenceContainer indicamos donde queremos que el contenido sea mostrado. Si indicamos content, será mostrado en el contenedor del centro de la página pero podemos poner header si lo queremos en encabezado, footer en pie de página o cualquier otro elemento de la página que queramos especificar.
En block indicamos la clase de nuestro bloque; name viene siendo un identificador único que nos puede servir como referencia a ese bloque (no es obligado especificar name pero si es recomendable) y template donde indicamos el fichero phtml que ejecutará el/los método/s del bloque para ser visualizados en la vista.

Dentro de la carpeta frontend creamos la carpeta templates y el fichero index.phtml.

En los ficheros phtml que es donde desarrollamos nuestras plantillas (o encontramos plantillas ya hechas) hacemos referencia al bloque utilizando la variable block.

Realizamos un cambio en el controlador. Tenemos que eliminar ResultFactory::TYPE_RAW pues esto ignora los layouts que tengamos. Para ello lo resolvemos implementando el método Execute.

Limpiamos la cache desde el terminal.

bin/magento cache:flush

Ejecutamos la página y vemos el resultado.

 

Acciones del controlador

Si queremos ejecutar según la acción del controlador, podemos hacer el siguiente cambio en el controlador.

Limpiamos la cache y al recargar la página es posible que veamos este error.

Esto se debe que una antigua firma aún está almacenada en caché. Lo podemos solventar cambiando al modo desarrollo ver documentación Magento mode.
En la documentación nos indica que al cambiar de producción a desarrollo, debemos eliminar los contenidos de los directorios de var/generation y var/di para evitar error inesperados.

rm -rf <your Magento install dir>/var/di/* <your Magento install dir>/var/generation/*

Al hacer el cambio a desarrollo o a producción, se limpian los contenidos de los siguiente directorios.
var/cache
var/di
var/generation
var/view_preprocessed
pub/static

Una vez leído la documentación y sabemos qué hace el comando, ejecutamos:

bin/magento deploy:mode:set developer

Es posible que nos aparezca el siguiente aviso por falta de permisos en ciertos directorios y hay que asignárselos.

Si todo ha ido bien nos indicará que ya está disponible el modo desarrollador.

IMPORTANTE: es posible que aún estando en modo desarrollo, nos pueda volver a pasar aunque limpiemos la caché. Ejecutaríamos el comando aún estando en modo desarrollo para solventarlo.

Recargamos la página y se nos muestra otra vez correctamente.

Lo que ocurre es que si recargamos como localhost/programas/magento2/holamundo/ también nos hará lo mismo. Eso se debe porque el controlador y la acción son index, luego los puede omitir. Pero podemos hacer un cambio renombrando la acción Index a Test y tenemos que renombrar también el nombre del fichero layout.

Recargamos la página con el enlace localhost/programas/magento2/holamundo para ver el error 404.

Recargamos la página con el enlace localhost/programas/magento2/holamundo/index/test y se ejecutará correctamente.

Nos quedará por ver como crear el modelo para completar el patrón de diseño MVC.