Dejar de lado los cambios con git stash

Resulta frecuente que un desarrollador sea molestado mientras trabaja en una nueva funcionalidad. A menudo, un mail que comienza por la palabra "URGENTE" es la causa de que el desarrollador deba detener su trabajo para corregir un posible bug.

En este caso, el desarrollador no debería hacer commit de su desarrollo para corregir el bug, ya que este commit estaría compuesto por modificaciones sin terminar con un código que no funciona y tal vez con líneas de depuración. Un commit no debe realizarse hasta que el proyecto ha sido probado y es funcional, lo que no corresponde a un trabajo en curso.

git stash puede tener varios propósitos. Imaginemos el caso de un desarrollador que desea hacer una demostración a un cliente (sin tenerla prevista de antemano). El desarrollador se encuentra en pleno desarrollo y algunas páginas regresan una página de error. Utilizando git stash, el desarrollador entrega su proyecto en el mismo estado que después de su último commit, conservando su desarrollo en curso para una próxima vez. El desarrollador puede hacer su demostración rápida y fácilmente sin hacer esperar al cliente.

git stash guardará todas las modificaciones a un lado. Estas no estarán incluidas en el directorio de trabajo ni el índice, no estarán tampoco presentes en el histórico...

Repositorios integrados con submódulos

Hoy en día, en un gran número de proyectos, los desarrolladores utilizan librerías. Por ejemplo, muchos proyectos web en la actualidad integran librerías como jQuery, Bootstrap o AngularJS. Estas librerías son necesarias para el funcionamiento del proyecto; es necesario tenerlas en nuestro repositorio principal (a menos que empleemos los servicios de un CDN que los albergue).

El problema que surge cuando los desarrolladores añaden fuentes de la librería directamente en su repositorio principal es que este código contaminará los commits y las estadísticas del repositorio con código que no ha sido creado por un desarrollador interno.

En efecto, con las fuentes directamente presentes en su repositorio, para cada actualización de la librería los desarrolladores deberán copiar los nuevos archivos de la librería y hacer un commit voluminoso con el mensaje «Actualización a Bootstrap 3.3.0».

El repositorio contendrá, por lo tanto, commits que no corresponden en absoluto al proyecto y que no son el fruto del trabajo del equipo de desarrollo. Además, si se realizan estadísticas en el repositorio, las adiciones y actualizaciones de las librerías las distorsionarán.

Existen soluciones a este problema. La solución más adecuada es utilizar un sistema de gestión de dependencias versionada. Este tipo de sistema permitirá listar las librerías que los desarrolladores necesitan y especificar la versión utilizada en el proyecto.

Por ejemplo, en un proyecto de Python, la herramienta de gestión de dependencias llamada PIP permite instalar y actualizar las librerías. Una convención, cuando se utiliza PIP, es crear un archivo requirements.txt en la raíz del repositorio. Este archivo contendrá la lista de dependencias utilizadas en el proyecto. Según las convenciones de otras tecnologías, el archivo de dependencias puede llamarse de forma diferente. Por ejemplo, en proyectos PHP utilizados con la herramienta Composer, el archivo se llama composer.json.

He aquí un ejemplo de archivo requirements.txt donde se especifican las librerías utilizadas en un proyecto Python/Django:

Django==1.8.2   
django-bootstrap3==5.4.0   
django-debug-toolbar==1.3.0   ...

Recuperar un commit erróneo

En cualquier tipo de desarrollo, a veces ocurre que un desarrollador agrega una regresión en su código. Una regresión significa que, durante el desarrollo de una funcionalidad o en la corrección de un bug, las modificaciones del desarrollador han supuesto hacer que otra parte del software no funcione. Las regresiones se añaden sin que el desarrollador se dé cuenta, y si no se requiere una prueba unitaria o funcional para detectar este tipo de error, entonces ésta sigue vigente hasta que un usuario o un desarrollador aborde el problema.

Git ayuda al desarrollador a encontrar el commit que añadió la regresión mediante una búsqueda dicotómica. En cada etapa de git bisect, Git sustituirá el directorio de trabajo por una versión anterior y habrá que indicar si el error sigue presente. Limita entonces el número de commits que pueden añadir el error y luego realiza una iteración modificando de nuevo el directorio de trabajo.

Una búsqueda dicotómica es un algoritmo de búsqueda que consiste en cortar el rango de valores en dos partes iguales en cada etapa. Al final de cada etapa, solo se guarda una mitad como rango de soluciones aceptables y luego se realiza una nueva etapa para reducir el rango de soluciones.

1. Utilización práctica de git bisect

Para explicar cómo funciona...

Registro de referencias (reflog)

Antes de hablar del diario de las referencias, se debe recordar que HEAD es una referencia (es decir, un puntero) que señala al commit más reciente de la rama actual.

Existe un registro de todas las referencias tomadas por el puntero HEAD en Git que se llama reflog (acceso directo de registro de referencia). Es un registro que va a almacenar todos los commits por donde pase el puntero. El reflog, por ejemplo, será capaz de guardar los cambios de rama o la adición de un commit.

Para visualizar este registro, se debe utilizar el comando siguiente:

git reflog

Utilizado en el repositorio de la parte dedicada a git bisect de este capítulo, este comando mostrará la siguiente salida:

1f28629 HEAD@{0}: checkout: moving from 
be902d9cc6cacfc7a927a8a07a5774a6aff6f0b4 to master 
be902d9 HEAD@{1}: checkout: moving from 
d42018b585c7a5b6b3593031faaefb09376bb14c to 
be902d9cc6cacfc7a927a8a07a5774a6aff6f0b4 
d42018b HEAD@{2}: checkout: moving from 
5b9094ff2f09fb74ec6c9965bdd02f6b6666ab88 to 
d42018b585c7a5b6b3593031faaefb09376bb14c 
... Salida truncada ... 
d42018b HEAD@{21}: commit: LICENCE : agregar 
2992238 HEAD@{22}: commit: README : agregar detalles 
a894f82 HEAD@{23}: commit (initial): README : agregar

La primera parte de la salida se ha generado por los cambios sucesivos de git bisect en el ejemplo anterior. La segunda...

Los hooks

Los hooks son scripts que se ejecutan durante acciones específicas en el repositorio. Le permiten automatizar ciertas tareas recurrentes como minificar archivos JavaScript, verificar el mensaje del commit o incluso realizar pruebas automatizadas.

1. Los diferentes tipos de hooks

Los hooks se pueden dividir en dos familias diferentes:

los hooks del lado servidor,
los hooks del lado cliente.

Los hooks del lado del servidor se ejecutan en los repositorios remotos. Permiten realizar acciones como:

comprobar que el usuario tiene derecho a hacer un push a una rama,
implementar una nueva versión del proyecto.

Los hooks del lado del cliente se ejecutan en los repositorios locales y permiten realizar acciones como:

minificar archivos JS/CSS después de un cambio de rama,
comprobar la sintaxis de los archivos,
lanzar las pruebas automatizadas.

Cada hook se identifica con un nombre que define cuándo lo ejecutará Git.

Los hooks del lado del servidor son los siguientes:

pre-receive: este hook es ejecutado por el servidor al inicio de la recepción de un push. Se utiliza para comprobar que se respeta la política de push (commit de acuerdo con las prácticas recomendadas, derecho a hacer un push en la rama, etc.). El push se puede rechazar si no se cumplen las condiciones del hook.
post-receive: este hook se ejecuta cuando se han realizado el push y la integración de los commits. Se puede utilizar para alertar a los usuarios de que se ha producido un envío. También se puede utilizar para iniciar procesos de implementación continua (un ejemplo está presente...

Las notas Git

Git ofrece un sistema para asignar comentarios a los commits. Este sistema de notas no reemplaza el mensaje de commit de ninguna manera. A diferencia de los mensajes de commit, las notas de Git no cambian el commit. Las notas se adjuntan a un commit sin modificarlo. Esto permite, por ejemplo, agregar detalles sobre un commit o seguir las revisiones de código de un commit.

En un equipo que usa Gt-Flow, también es bastante posible en el último commit de las ramas hotfix agregar una nota con un indicador #readyToDeploy para especificar que el commit está listo para ser implementado. Este tipo de flag no tendría nada que ver en un mensaje de commit porque no se podría eliminar, mientras que con las notas es posible.

1. Crear una nota

Para crear una nota en un commit, use el siguiente comando:

git notes add <commit>

Puede usar el argumento -m para definir el mensaje o dejar que Git abra el editor de texto.

Una vez que se valida el mensaje, Git crea un nuevo objeto correspondiente al mensaje y lo adjunta al commit. Debemos permanecer atentos al grabar una nota en un commit a partir de una referencia dinámica. Una nota guardada en el master ya no coincidirá con el master cuando se le haya agregado un nuevo commit.

2. Mostrar las notas

Hay varias formas de ver las notas a utilizar según la necesidad.

a. Lista de notas

Para listar las notas de depósito, use el siguiente comando:...

Las herramientas de Git