• Básicos Git (I): Cherry pick
• Básicos Git (II): Rebase
• Básicos Git (III): Revert
• Básicos Git (IV): Reset
• Básicos Git (V): Amend
• Básicos Git (VI): Stash

VisualStudio proporciona una opción de deshacer cambios que permite deshacer los cambios a los ficheros antes de crear el commit, esta opción de deshacer no realiza ninguna acción en Git.

Por ejemplo si realizamos cambios en uno o varios ficheros veremos que en la sección changes del plugin nos indica los ficheros que hemos cambiado y tendremos la opción de realizar undo changes.

Esto eliminará los cambios pendientes y dejará los archivos en su estado original sin crear un commit.

Revert pertenece a ese grupo de comandos pensado para deshacer cambios, en este caso revert lo que hace es crear un nuevo commit que contiene los ficheros originales previos al cambio, en este caso Git si se ve afectado.

El historial se mantiene por lo que no hay problema de usarlo con el equipo de desarrollo, si alguien del equipo está trabajando con la rama o la fusiona con una existente solo tendré que añadir el nuevo commit.

En el ejemplo hemos creado una rama develop y queremos deshacer el commit marcado en rojo (#3).

A continuación para deshacer un commit solo tendremos que ir al historial de la rama, seleccionar el commit que queremos deshacer y seleccionar la opción revert.

Esto provocará un nuevo commit con el nombre por defecto Revert «comentario del commit a deshacer».

Este revert se queda en el historial, por lo tanto se podrá ver tanto el commit original como el commit que lo deshizo, este nuevo commit lo que contiene son los contenidos originales que había en el commit #2 que fueron modificados por el commit #3.

A su vez este contenido de la forma habitual se puede fusionar con la rama master por lo que nos quedaría un árbol así.

• Básicos Git (I): Cherry pick
• Básicos Git (II): Rebase
• Básicos Git (III): Revert
• Básicos Git (IV): Reset
• Básicos Git (V): Amend
• Básicos Git (VI): Stash

Existe otra forma de hacer una fusión de ramas y es con un comando rebase. Rebase lo que hace es insertar una rama dentro de otra en el mismo punto donde se creo de tal forma que parezca una sola rama.

Situación inicial

Para poder entenderlo bien vamos a manejar dos ramas, master y develop, creamos dos commits en develop y otros dos en master, el orden no es importante (Figura 1).

En este punto master y develop divergen y tienen commits diferentes, vamos a aplicar un rebase para crear una sola rama con todos los cambios.

Aplicando rebase

Para tener una sola rama rama vamos a hacer un rebase, nos posicionamos en la rama master con los parámetros que se ven en la imagen y pulsamos rebase.

Conflictos

Esto provocará varios conflictos, el rebase irá aplicando primero cada cambio de master a develop, los conflictos que se aplicarán a develop son:

1. El primer commit de develop (que sería el existente) con el primer commit de master (Commit C1).
2. El resultado del commit anterior con el segundo commit de master (Commit C2).
3. Así sería sucesivamente si hubiera más commits.

Estos nuevos commits tendrán como comentarios los correspondientes a su commit de master.

Ahora para terminar el rebase solo queda aplicar estos cambios de la rama develop en la rama master provocando un último conflicto (Commit R), en este caso si que habrá que indicar un comentario.

Resultado

En la imagen anterior si nos fijamos en la rama master vemos que están todos los commits de develop insertados en la rama master (recuadro rojo) justo en el punto que se creo la rama develop, por lo que en master queda un arbol límpio con todos los commits.

Este sistema se suele utilizar más para actualizar ramas locales que para actualizar la rama master ya que se está alterando el historial de una rama (master en este caso).

Esto también provoca que se altere el cronograma por lo que podemos ver commits más recientes que aparecen más tarde en el historial, ya que prima el orden de creación más que la fecha de los mismos.

Este sistema también puede crear un problema para el resto de desarrolladores que hayan creado otras ramas de master a posteriori lo que genera conflictos a veces complicados de resolver.

Generalmente no se recomienda hacer un rebase sobre ramas remotas por el peligro que conlleva para otros desarrolladores, sin embargo en ramas locales suele haber más disparidad de criterio.

• Básicos Git (I): Cherry pick
• Básicos Git (II): Rebase
• Básicos Git (III): Revert
• Básicos Git (IV): Reset
• Básicos Git (V): Amend
• Básicos Git (VI): Stash

El uso básico de Git es bastante conocido sin embargo hay algunos conceptos que se suelen nombrar y quizás a veces inducen al error, en este caso comentaré los más habituales que se suelen ver en el plugin de VS2017 para Git.

Para este ejemplo se ha creado una rama master y una rama develop que hereda de master. En el historial de Git del plugin de VisualStudio se vería de la siguiente forma.

Aquí podemos ver que nos está indicando con la marca roja master que master ha tenido commits hasta el commit id 9e3acdb5, con la marca roja develop vemos que esta rama está avanzada y tiene más commits que master.

Para este ejemplo solo hemos añadido un fichero en master y después en la rama develop hemos continuado haciendo modificaciones sobre este fichero.

Cuando fusionemos las ramas las dos estarán sincronizadas por lo que veremos algo como esto, las dos marcas rojas alineadas.

Cherry pick

El concepto de cherry pick es poder coger uno o varios commits de una rama y copiarlos a otra rama distinta, este concepto lo vamos a aplicar a la fusión (merge) de ramas.

La idea de un merge es fusionar dos ramas entre sí, la forma más habitual es fusionar en una rama destino (en este caso master con los commits en blanco) una rama origen (develop con los commits en azul) incluyendo en la rama destino tantos commits y en el mismo orden como commits tiene la rama origen. (Figura 1).

Existe otra opción que consiste en fusionar todos los cambios de una rama origen en una rama destino en un solo commit, es decir todos los commits de la rama origen se agrupan en uno solo y es este el que se inserta en la rama destino. (Figura 2).

El comando merge por defecto no hace un cherry pick, el plugin de VisualStudio permite hacerlo de dos formas diferentes, en ambos casos el comentario que se verá en la rama destino será el del último commit.

Cherry pick de una rama

En el caso de una rama entera habría que posicionarse en la rama origen de los commits y después hacer click en la opción cherry pick en la rama que va a recibir los commits.

En este ejemplo la rama develop va a recibir todos los commits de master.

Esta acción genera un conflicto al contrario que un merge normal, esto se debe a que cherry pick solo transfiere commits no es un merge en el sentido estricto, los errores de conflicto se solucionan de la forma habitual.

Cherry pick de commits individuales

Otra opción es seleccionar específicamente uno o varios commits y transferirlos a otra rama, en este caso nos situamos en la rama destino y abrimos el historial de la rama origen, seleccionamos los commits que nos interesen y hacemos click en cherry pick.

En este caso solo habrá conflictos si seleccionamos varios commits o elegimos uno que no sea inmediatamente posterior tanto en la rama origen como destino, es decir que si hicieramos cherry pick de cada commit en el mismo orden en la rama destino no deberíamos tener conflictos, realmente esta última forma es lo mismo que emular un merge normal.

Cuando vi esta escena de la grandísima serie que es Halt and Catch Fire tuve que sobreponerme a las ganas de empezar a aplaudir, esta serie que en muchos momentos recoge lo mejor del mundo tecnológico lo había vuelto a conseguir y si a eso le sumamos este artículo que leí hace poco (los programadores son más importantes para las empresas que los directores de TI) la cosa se pone aún mejor.

Esta escena muestra bastante bien lo que muchos desarrolladores piensan sobre sus jefes de proyecto y posiblemente los jefes de proyecto pensarán aquello de “si te digo todo lo que pasa que no te quiero contar…”, esta situación acaba llevando a un sutil enfrentamiento y sectarismo entre “gente con traje vs gente sin traje”.

Siempre ha existido un miedo irracional hacia lo desconocido que confunde y a menudo irrita al ser humano haciéndole tomar actitudes que generalmente no son muy correctas o sensatas, más o menos la actitud que toma un jefe de proyecto ante un grupo de desarrolladores cuando estos le intentan explicar algo, generalmente el jefe de proyecto no es técnico -ni intención que tiene- solo le interesa saber cuándo se va a entregar algo y que no le engañen diciendo cuatro meses cuando pueden ser tres.

De todas formas, ante la duda el jefe de proyecto siempre sacará alguna queja –puede que sin demasiado sentido- y de paso te quitará dos semanas, -que seguro que ya será menos el tiempo que hace falta-, lo que el jefe de proyecto no sabe es que ante esto la próxima vez el desarrollador le meterá un mes más, como el lazarillo de Tormes si tu coges dos uvas yo cojo tres, pero no nos decimos nada, -y la rueda del absurdo sigue girando-.

Tomando una actitud “zen” -que llegado cierto punto es la mejor opción- la respuesta fácil sería decir, las probabilidades de que un proyecto se cumpla en plazo es inversamente proporcional a su tamaño, es decir que si dices que entregas en una semana puede que sea verdad, pero si dices que entregas en un año, seguro que al final es año y tres meses.

En cualquier caso esta sensación de “no sé qué me han contado” del jefe de proyecto también la tiene el cliente, el jefe de proyecto que no se acaba de enterar muy bien le habla a su cliente sobre el proyecto -y le transmite esta inseguridad-, este acaba haciendo lo mismo, realmente no se está enterando muy bien de que le están hablando pero tampoco va a parecerlo así que plantea dudas, quejas y plazos que igual no tienen nada que ver con el proyecto, y en particular con lo que el cliente realmente necesita -pero llegado ese punto el jefe de proyecto hace un «si a todo»-, lo cual se traslada finalmente al equipo de desarrollo que se queda pensando aquello de “hay días que no se para que me molesto”, -el grado de frustración pasa de lineal a exponencial-.

Algunos dirían que esto se arregla con un jefe de proyecto con antecedentes tecnológicos, el problema es que la tecnología avanza a veces demasiado rápido y es fácil quedarse atrás y acabar volviendo al punto anterior encima con la idea de “yo que fui desarrollador…” el desenlace final suele ser aún peor.

Sin embargo hay matices, depende de la empresa, del cliente, con quien trabajes… es posible que los plazos se puedan mantener y todo vaya bien, pero si la empresa no es muy grande y no tiene capacidad negociadora, o el cliente es demasiado importante o el presupuesto escaso… entonces los plazos se piden por cortesía pero es probable que acaben siendo otros –y volvemos al primer punto-.

Hace algún tiempo desde una empresa me contactaron para un proceso de selección que necesitaba a una persona que sirviera de enlace entre el equipo de desarrollo y el de gestión, que fuera capaz de “entender” a los programadores y luego “traducir” todo eso en plazos y tiempos de forma razonada, algo así como “no sé si los desarrolladores me engañan o es verdad, pero tengo que dar una fecha y plazos que tengan sentido y se cumplan».

Yo he de reconocer que me alegré, no porque me hubieran contactado –que también- sino que por fin después de años alguien se había dado cuenta que hace falta “un intermediario” que sea capaz de hacer ese trabajo, que por un lado sea técnico –generalmente de buen nivel- y ejerza como tal pero que también entienda que los proyectos se hacen para entregarlos y sea capaz tanto de trasmitir esa idea al equipo, así como a su vez transmitir a gestión por parte del equipo aquella gran frase de “nueve mujeres no paren en un mes”.

De hecho, yendo más allá en los últimos tiempos he tenido ocasión de observar empresas creadas solamente por desarrolladores y aunque es verdad que hace falta gente de todo tipo en una empresa- la verdad es que les está yendo muy bien.

Quizás lo que algunas empresas necesitan es un perfil así, no solo mejorarían su productividad, sino que la empatía entre “gente con traje vs gente sin traje” aumentaría, lo que posiblemente es el mayor beneficio.

 

 

 

Finalmente suele ser útil y práctico poder depurar las aplicaciones, principalmente he manejado dos sistemas de depuración en PHP, XDebug y Zend Debugger, Zend Debugger es propietario y XDebug es libre, el problema principal viene dado porque el binario de Zend Debugger no está disponible para la arquitectura arm de Raspberry así que optaremos por XDebug.

Así mismo hay varios editores que permiten depurar con XDebug, en este caso el ejemplo lo hago con PHPStorm, primero hay que hacer la configuración del lado servidor.

Una vez instalado el módulo de XDebug (verificar con phpinfo()) tendremos que configurarlo, editamos el fichero xdebug.ini y establecemos los siguientes valores.

zend_extension=/usr/lib/php5/20131226/xdebug.so
xdebug.remote_enable=1
xdebug.remote_handler=dbgp
zdebug.remote_mode=req
xdebug.remote_host=192.168.1.99
xdebug.remote_port=9000
xdebug.idekey="phpstorm"

Lo importante aquí es establecer como xdebug.remote_host la dirección IP del cliente, es decir donde está instalado PHPStorm que es desde desde donde queremos depurar y lo mismo para el puerto, estas opciones normalmente son configurables a partir del entorno pero el puerto por defecto 9000 es estándar.

xdebug.idekey es un valor que se pasa al depurador para identificar la sesión no es necesario establecerlo pero suele ser buena idea indicar el mismo que el IDE usado.

Si se quiere poder depurar desde cualquier máquina se puede usar el valor xdebug.remote_connect_back, para más detalles ver aquí.

Como ya vimos una buena opción es compartir vía Samba la carpeta de Apache de la Raspberry y usarla para editar directamente los ficheros eso nos ahorra de cara a PHPStorm el paso de desplegar, por lo tanto de cara a crear un nuevo proyecto en PHPStorm indicamos que trabajaremos en local con la ventaja añadida de que tendremos también git integrado (si está configurado git en la carpeta del servidor).

Ahora solo nos queda desde el menú «Run» usar la opción «Start Listening for PHP Debug Connections«.

Ahora desde aquí creamos los enlaces que se usará para arrancar el depurador y conectar al cliente, lo recomendable es arrastrarlos a la barra de navegación del navegador que estemos usando, principalmente usaremos «Start debugger«.

Una vez que empiece el sistema de depuración PHPStorm nos mostrará una ventana en la que nos indicará cual es el mapeo correspondiente entre el fichero a depurar y la ubicación física del mismo, si no puede realizar esta asociación al crear un punto de interrupción aparecerá éste con una X indicándolo, esto es muy probable que pase para los ficheros fuente que están fuera de las carpetas públicas (habitual si se usa frameworks tipo Symfony) en ese caso desde «Run -> Edit Configurations» veremos debajo de «PHP Remote Debug» el host detectado dentro de éste solo tenemos que indicar los mapeos correspondientes dentro del servidor (las rutas físicas de Linux), es necesario pulsar enter para que se quede la ruta establecida.

 

Hay muchas formas automatizadas de crear un servidor de desarrollo, en este caso vamos a usar una Raspberry Pi con sistema LAMP, primero configuraremos el sistema LAMP y después configuraremos las carpetas.

Vamos a considerar que tenemos una empresa Acme que tiene un proyecto de nombre Coyote.

Primero tenemos que actualizar la Raspberry para ponerlo todo en orden.

Se puede actualizar el kernel así como el firmware de Raspberry aunque no es estrictamente necesario, esto se realiza con el comando rpi-update, si no está instalado se puede descargar vía apt-get.

# sudo rpi-update

Ahora actualizamos la distribución, este paso es recomendable.

# sudo apt-get update
# sudo apt-get upgrade
# sudo apt-get dist-upgrade

Ahora instalamos primero la base de datos, en este caso MariaDB, durante el proceso de instalación se pedirá una contraseña para el usuario root, se recomienda indicar una.

# sudo apt-get install mariadb-server mariadb-client

Ahora instalamos el servidor Apache 2.

# sudo apt-get install apache2

Ahora instalamos PHP 5 y el módulo de PHP 5 para Apache 2.

# sudo apt-get install php5 libapache2-mod-php5

PHP 5 tiene muchos módulos pero uno de los más importantes y que va a ser necesario es el módulo de PHP 5 para base de datos, en este caso para MariaDB

# sudo apt-get install php5-mysqlnd

Como optimizador de código intermedio de PHP 5 vamos a instalar ACPu.

# sudo apt-get install php5-acpu

Ahora solo queda reiniciar Apache 2.

# sudo service apache2 restart

Ahora vamos a usar Samba para poder acceder a la carpeta de Apache desde Windows, si trabajamos en entornos híbridos es una comodidad para poder acceder al código fuente.

En Raspberry vamos a usar la carpeta por defecto de Apache para desplegar (/var/www/apache/html) en esta carpeta creamos la carpeta Acme y dentro de esta la carpeta Coyote.

#cd /var/www/html
#sudo mkdir acme
#cd acme
#sudo mkdir coyote

Ahora podemos instalar Samba.

#sudo apt-get install samba samba-common-bin

Una vez hecho esto vamos a crear un usuario por proyecto, en este caso creamos el usuario coyote, no nos interesa que tenga ni una shell ni una carpeta de usuario porque es un usuario que solo vamos a usar para acceder por red y así proporcionamos más seguridad al sistema, en resto de los valores que nos pida podemos establecer cualquier valor.

# sudo adduser -shell /bin/false --no-create-home coyote

Ahora añadimos el usuario a la lista de usuarios de Samba y le indicamos una contraseña para acceder por red.

# sudo smbpasswd -a coyote

Tenemos que dejar que el usuario de apache (www-data) pueda acceder a las carpetas para poder mostrarlas, pero también tenemos que dejar que el usuario coyote pueda acceder y realizar modificaciones desde el exterior a través de la red, así que vamos a crear el grupo acme y añadir a ambos usuarios a ese grupo.

# sudo addgroup acme
# sudo adduser coyote acme
# sudo adduser www-data acme

Empezamos con los permisos, vamos a asignar como propietario de los ficheros a www-data pero el grupo para la carpeta acme lo vamos a asociar al grupo acme, la carpeta html la dejamos como está (propietario y grupo para root para permisos 775).

# cd /var/www/html
# sudo chown -R www-data acme
# sudo chgrp -R acme acme

Ahora asignamos permisos, damos permiso total al usuario y grupo.

# sudo chmod -R 770 *

Tanto el usuario coyote como el usuario www-data necesitan acceder a la carpeta así que vamos a establecer el bit setgid para que los permisos se orienten por grupo y no por usuario así ambos usuarios podrán utilizar los ficheros indistintamente y también configuramos los permisos en la carpeta.

# sudo chmod g+s acme
# sudo chmod -R 755 acme

Ahora solo nos queda hacer visible la carpeta a través de la red, para eso modificamos el fichero /etc/samba/smb.conf y añadimos lo siguiente.

[coyote]
comment = El proyecto Coyote de Acme
path = /var/www/html/acme/coyote
read only = No
valid users = coyote
write list = coyote #Usuarios que pueden escribir
create mask = 0660 #Mascara de creación de archivos
directory mask = 0770 #Máscara de creación de directorios

Finalmente podemos comprobar que toda la configuración es correcta con el uso del comando testparm.

# testparm

Que debería indicarnos que todo es correcto, si es así reiniciamos Samba.

# sudo service smbd restart