A la gran mayoría de los que alguna vez hemos usado o seguimos usando GIT nos ha pasado que hacemos un cambio en nuestro proyecto, dígase una nueva funcionalidad o una simple mejora, hacemos nuestro respectivo commit y, justo antes del push nos damos cuenta que hemos estado trabajando en una rama equivocada o simplemente ese commit no tenía por qué enviarse aún.
git cherry-pick es un comando que nos permite literalmente… agarrar un commit y moverlo a la rama actual sobre la que se esté trabajando, normalmente master head. git cherry-pick suele usarse para deshacer cambios pero sin perder lo ya trabajado (obvi).
Un punto a favor para el uso de git cherry-pick el cual se merece su propio párrafo; es el poder de corregir bugs de manera rápida de tal forma que no afecte a los demás desarrolladores y, al mismo tiempo les corrija a ellos ese mismo bug. Ejemplo: te das cuenta que tenías un error tal vez no de código pero sí de funcionalidad o incluso lógico antes de hacer push. Los demás ya tienen ese último update e incluso más commits de otros desarrolladores y ahora lo que necesitas es solucionarlo antes de que pase más tiempo. Bueno la solución aquí y haciendo uso de git cherry-pick; es crear un commit donde se corrija ese bug y después enviarlo al tope de la rama principal (cherry-picked).
¿Pero qué rollo cómo funciona o qué?»
Pues ahí te va! Supongamos que tienes la siguiente estructura en tu árbol de git
Según lo que explicamos anteriormente, en algún punto de tu historia olvidaste algo, hay un error, o es extrictamente necesario hacer un cambio. Digamos que el cambio se tenía que hacer en el commit «B», sin embargo; el historial ya avanzó…
En este punto podemos ejecutar el siguiente comando:
[shell]git log –oneline[/shell]
El resultado obviamente va a ser diferente pues cada quien nombra sus commits de acuerdo a sus mejores prácticas, pero aquí lo que nos interesa es el ejemplo ; )
Otra cosa que nos interesa es el identificador del commit (commit-hash) pues lo vamos a necesitar más adelante.
Ojo: en esta última imagen solo estoy señalando el commit-hash de «B» puesto que aquí fue donde cometimos el error, omisión, lo que sea (de aquí en adelante lo llamaremos bug), NADA MÁS.
Creamos una rama hasta este punto (E)
[shell]git checkout -b new-sample-branch[/shell]
Listo! Ya estamos trabajando en una copia, una nueva rama.
Es importante aclarar que en esta rama crearemos un commit única y exclusivamente para solucionar el bug del commit «B». Corregimos lo que se tenga que corregir, hacemos commit y copiamos el hash de ese último commit.
[shell] git add .[/shell]
[shell] git commit -m ‘En este commit se arregló el bug’ [/shell]
la rama «new-sample-branch» quedaría así mira…
Nuestro árbol ya va tomando más forma jajaja
Si nos fijamos en la rama principal, el historial ya avanzó con un commit (yisus craaaaaist). Espérate! no pasa nada, lo que vamos a hacer es lo siguiente:
[shell]git checkout master[/shell]
[shell]git cherry-pick f115733[/shell]
Nos cambiamos a la rama principal, ejecutamos git cherry-pick más el hash del commit que ya habíamos dicho y VOILÀ. Si todo sale bien entonces ya tenemos ese update en nuestra rama principal y corregido el bug.
Ahora si ejecutamos git log –oneline veremos algo como esto.. (para la rama principal es obviamente un nuevo commit, es por eso que el hash ha cambiado)
En términos muy mortales lo que hicimos fue, básicamente hacer una clon, corregir el bug y después traernos esa corrección a la rama original. El árbol queda de la siguiente manera pero ya podemos eliminar esa rama secundaria pues en teoria ya de nada nos sirve… Capisce?
git branch -D new-sample-branch
Eliminamos la rama con la opción «-D» mayúscula para forzar su borrado, pues si te fijas nunca hicimos merge con la rama principal ; ) trucazo jajajajaja
Nuestro árbol ahora se ve mucho mejor!
A partir de aquí podemos continuar como si nada hubiera pasado y los demás programadores al hacer pull, obtendrán esta corrección como un commit común y corriente. Recuerda que tu rama principal no necesariamente tiene que ser master, puede ser cualquiera (develop, release, etc) según la estructura o reglas de tu proyecto.
Hay muchas opciones (parámetros) para usar todo el poder del comando cherry-pick, muuuuuchas consideraciones (que afecta el historial, y luego qué onda con los commits duplicados, que esto y aquello) pero eso ya cada quien lo tendrá que valorar pues cada uno le dará el uso que necesite y, no hay nada como echarse un clavado en la documentación oficial.
Cherry-pick no es sustituto de ningún otro comando, es una herramienta útil pero hay que tener cuidado siempre, puede que existan más cosas en juego que no sólo una simple rama para corregir un bugsito. Así que se puede hacer la prueba con algo básico para ver su comportamiento y aprender cómo funciona, ya después le calas en producción… Dios te bendiga!
Aquí está la Documentación oficial
Y si no le andas fallando al inglés esta página está muy chingona, chécale!
Git Cherry Pick
