Piques Git – cherry pick y git clean

Git es una herramienta fundamental en mi trabajo diario desde hace unos cuantos años, pero todavía sigo aprendiendo cosas nuevas todo el tiempo. Distintos proyectos tienen distintos procesos de  trabajo, lo que nos ayuda a aprender cosas que no conocíamos y que hacen más práctico el día a día. En este post voy a escribir sobre algunas cosas nuevas que empecé a usar seguido recientemente gracias a la naturaleza del trabajo en el cliente Ruby para Elasticsearch.

Eliminar todos los archivos nuevos que no han sido agregados a staging

Vengo trabajando bastante en generación de código. Esto da lugar a mucho ensayo y error, poco probable que el código generado sea exactamente lo que se necesita en la primera prueba. Además al ir programando incrementalmente, un primer paso es generar el archivo, después agregarle una parte, después otra, y así. Por la forma de trabajar con esto, varias veces tengo que ir y eliminar el código generado. Y el comando que vino al rescate con esto es git clean.

git clean elimina archivos de nuestro repositorio que no estén bajo control de versiones. Entonces, si modificamos un archivo y queremos descartar los cambios, podemos usar git checkout archivo y volverá a su estado anterior. Pero si el archivo es nuevo, podemos usar git clean. El comando elimina archivos desde el directorio en que es ejecutado o le podemos pasar un directorio como parámetro.

Por defecto el comando no entra en directorios que no están registrados en git para evitar eliminar demasiada cosa. Con el comando -d podemos especificarle que entre recursivamente en los directorios. Si le especificamos un path (o ruta), este parámetro es irrelevante, porque va a eliminar todos los archivos que macheen con la ruta especificada.

Con el parámetro -f le decimos que elimine archivos a la fuerza. Generalmente uso:

git clean -f [ruta]

Podemos leer más sobre git clean en la documentación oficial.

Cherry picking de rangos de commits

Otra cosa que hacemos bastante en el equipo de clientes para Elasticsearch es backporting. Como mantenemos distintas versiones de los clientes (v6.x, v7.x y master), tenemos que aplicar modificaciones de una versión a otra. Se le llama “backport” a la acción de aplicar cambios o parches a una versión antigua del software originados en una versión más nueva. Pero en mi caso por lo menos los cambios pueden ir en cualquiera de las direcciones, dependiendo la situación. No sé si hay existe el término “forwardport” o “branchport” cuando es de una rama a otra 🤷‍♂️

Volviendo al tema, el comando cherry-pick nos permite aplicar los cambios de uno o varios commits en la rama actual. Y en el caso de backporting que viene bastante a la mano es una sitación como la siguiente: Abrí un Pull Request a la rama 7.x con 5 commits que implementan algo nuevo. Después de asegurarme que todo está en orden, quiero hacer backport de los cambios a la rama 6.x. Así que puedo hacer cherry-pick del rango de commits involucrados en el cambio en la rama:
git cherry-pick hash_primer_commit..hash_último_commit 🙌

También podría hacer un rebase o merge de la rama que implementa ese cambio, pero el cherry-pick es útil en estos casos, porque a veces algunos de los commits sólamente aplican a una rama en particular y podemos hacer cherry-pick sólo de los que necesitamos. Más información en la documentación oficial.

Vengo usando tanto cherry-picking que agregué un alias en mi archivo de configuración de git (~/.gitconfig):

[alias]
  cp = cherry-pick

Esto me permite abreviar el comando a git cp [commit].

Git es una de mis tecnologías favoritas, me facilita bastante la vida y me encanta aprender cada vez más sobre su uso. En este post compartí estos piques y de paso comento un poco sobre el trabajo en Elastic. Si les interesa que escriba más sobre Git, tienen algún pique que quieran compartir, o preguntas sobre Git (o mi trabajo) les invito a dejar un comentario.