Noticias

Guía de supervivencia GIT

La gestión de versiones es un requisito indispensable en cualquier equipo de desarrollo. Aunque el departamento, estuviera compuesto por una sola persona, aún así sería conveniente que todo el código estuviera bajo alguno de los sistemas de control de versiones disponibles.

La gestión de versiones nos permite revertir nuestro trabajo a un estado anterior, comparar los cambios, ver las modificaciones que ha realizado cada usuario, así como trabajar en equipos desde distintas ubicaciones, tener distintas líneas de desarrollo, compartir código etc.

El objetivo es tener un control total del proyecto y tener siempre gestionadas las diferentes versiones del mismo y olvidarse de los pobres programadores tirándose del pelo y gritando “Quién ha sido el que ha machacado mi código!!!”


En el artículo de hoy, vamos a dar un repaso, por lo que sería un día típico como desarrollador, dentro que un equipo colaborativo. Veremos como actualializar el código, gestionar una nueva rama para nuestra funcionalidad, subir nuestro código y resolver alguno de los problemas típicos con los que nos podemos encontrar durante el proceso.

Por su amplia difusión, robustez, rapidez, flexibilidad y fiabilidad, veremos GIT como sistema para la gestión de versiones.

Imaginemos que hoy es nuestro primer día de trabajo, uno de los primeros correos que recibiremos en nuestra cuenta será el que nos indique los datos de acceso al repositorio de código del proyecto, además también deberemos tener acceso a la pila de funcionalidades que restar por añadir en la aplicación. Nuestra primera funcionalidad en la que trabajar, va a ser la corrección de un copy, es un simple error tipográfico y una simple excusa para desarrollar el post.

Es momento de ponernos manos a la obra. Para ello, lo primero que tenemos que bajar una copia del proyecto actualizada. Para ello, lo primero es clonar el repositorio en nuestro equipo: 

git clone https://github.com/miguelvilata/git-survival.git

Por defecto, la rama que se baja es la rama master, normalmente la rama que está más adelantada, con los últimos progresos del equipo, es la rama develop, entonces lo siguiente que haremos será bajarnos la rama develop.

cd git-survival
git fetch origin develop:develop
From github.com:miguelvilata/git-survival
 * [new branch]      develop    -> develop

Una vez contamos con la rama develop actualizada, podemos sacar a partir de esta, nuestra rama de trabajo sobre la que poder implementar la funcionalidad que nos han encargado. En nuestro caso la llamaremos feature/fix-copy

$ git checkout -b feature/fix-copy

Ahora llega el momento de resolver el problema y dependiendo de si es una nueva característica pues crear el test pertinente.

Una vez todo listo, es hora de hacer nuestra primera contribución al proyecto. Antes de proceder, siempre es bueno comprobar que sólo vamos a subir los cambios que hemos realizado y que no por error se puedan colar algun otro cambio no deseado, para ello utilizamos:

git status

Esta orden nos debe devolver los archivos con cambios respecto al proyecto original.

Ahora si ejecutamos nuestro primer commit que describa lo mejor posible nuestra nueva funcionalidad o fix.

git commit -am "Fix text intro on contact page."

Llega el momento de subir nuestra rama para solicitar su incorporación a la rama principal develop, pero antes recuerda que estamos trabajando en equipo y es posible que alguien pueda haber integrado nuevo código en la rama develop de la que partimos para realizar nuestra corrección, es por ello que siempre debes comprobar que esos posibles cambios no estén afectando a los realizados por tí, para ellos tendrás que hacer un rebase de la rama develop actualizada, vamos a ello.

git checkod develop
git pull origin develop 
git checkout feature/fix-copy
git rebase develop

En caso de producirse algún conflicto es nuestra tarea resolverlo antes de subir la rama para su integración con develop.

Finalmente subiremos la rama al repositorio:

git push origin feature/fix-copy

Según la operativa de cada empresa ahora puede seguir un proceso distinto el que yo recomiendo es el de la creación de un Pull Request desde la vista de ramas de tu repositorio, esta Pull Request debe apuntar normalmente a la rama develop, entonces mediante el sistema que utiliceis dentro de la empresa se solicitará la revisión del código por otro compañero copiando el enlace al Pull Request, en estos momentos el compañero nos puede o bien aprobar el PR o bien hacernos alguna indicación sobre algún punto de mejora, dependiendo del caso tendremos que modificar el código para mejorarlo y volver a solicitar el PR, o bien tras ser aprobado procederemos simplemente ya a su integración megeándolo hacia develop.

Para poder volver ahora con otra tarea sólo nos queda restablecer nuestras ramas locales, para ello actualizamos nuestra rama develop y borramos la rama antigua.

git checkoud develop
git pull origin develop
git branch -d feature/fix-copy

Posiblemente a muchos les parecerá un post un tanto simple, pero me ha parecido interesante para publico no habituado el mostrar lo que es un flujo típico con GIT en el día a día de una empresa y una buena excusa para publicar en el blog ;-).

En futuras entradas avanzaremos más en la resolución de conflictos, creación de releases siguiendo las directrices del versionado semántico, tratamiento de hotfix, etc.


GIT


Compartir mola!!