Seguimos con GIT.
Supongamos que estás trabajando en alguna prestación, y que por alguna razón, necesitas volver a una versión vieja y poner temporalmente algunos ”print” para ver como funciona algo. Entonces:
$ git commit -a
$ git checkout HASH_SHA1
Ahora puedes agregar cualquier código temporal horrible por todos lados. Incluso puedes hacer commit de estos cambios. Cuando termines,
$ git checkout master
para volver a tu trabajo original. Observa que arrastrarás cualquier cambio del que no hayas hecho commit.
¿Que pasa si quisieras cambiar los cambios temporales? Fácil:
$ git checkout -b sucio
y haz commit antes de volver a la branch master. Cuando quieras volver a los cambios sucios, simplemente escribe:
$ git checkout sucio
Al fin podemos contar toda la historia:los archivos cambian al estado pedido, pero debemos dejar al branch master. Cualquier commit de aquí en adelante, llevan tus archivos por un nuevo camino, el podrá ser nombrado posteriormente.
En otras palabras, luego de traer un estado viejo, Git automáticamente te pone en una nueva branch sin nombre, la cual puede ser nombrada y salvada con git checkout -b.
Algunos proyectos requieren que tu código sea evaluado antes de que puedas subirlo. Para hacer la vida más fácil para aquellos que revisan tu código, si tienes algún cambio grande para hacer, puedes partirlo en dos o mas partes, y hacer que cada parte sea evaluada por separado.
¿Que pasa si la segunda parte no puede ser escrita hasta que la primera sea aprobada y subida? En muchos sistemas de control de versiones, deberías enviar primero el código a los evaluadores, y luego esperar hasta que esté aprobado antes de empezar con la segunda parte.
En realidad, eso no es del todo cierto, pero en estos sistemas, editar la Parte II antes de subir la Parte I involucra sufrimiento e infortunio. En Git, los branches y merges son indoloros (un termino técnico que significa rápidos y locales). Entonces, luego de que hayas hecho commit de la primera parte y la
hayas enviado a ser revisada:
$ git checkout -b parte2
Luego, escribe la segunda parte del gran cambio sin esperar a que la primera sea aceptada. Cuando la primera parte sea aprobada y subida,
$ git checkout master
$ git merge parte2
$ git branch -d parte2 # ya no se necesita esta branch
y la segunda parte del cambio está lista para la evaluación. ¡Pero esperen! ¿Qué pasa si no fuera tan simple? Digamos que tuviste un error en la primera parte, el cual hay que corregir antes de subir los cambios. ¡No hay problema! Primero, vuelve a la branch master usando
$ git checkout master
Soluciona el error en la primera parte del cambio y espera que sea aprobado. Si no lo es, simplemente repite este paso. Probablemente quieras hacer un merge de la versión arreglada de la Parte I con la Parte II:
$ git checkout parte2
$ git merge master
Ahora es igual que lo anterior. Una vez que la primera parte sea aprobada:
$ git checkout master
$ git merge parte2
$ git branch -d parte2
y nuevamente, la segunda parte está lista para ser revisada. Es fácil extender este truco para cualquier cantidad de partes.
Quizás quieras trabajar en todos los aspectos de un proyecto sobre la misma branch. Quieres dejar los trabajos-en-progreso para ti y quieres que otros vean tus commits solo cuando han sido pulcramente organizados. Inicia un par de branches:
$ git checkout -b prolijo
$ git checkout -b mezcla
A continuación, trabaja en lo que sea: soluciona bugs, agrega prestaciones, agrega código temporal o lo que quieras, haciendo commits seguidos a medida que avanzas. Entonces:
$ git checkout prolijo
$ git cherry-pick HASH_SHA1
aplica un commit dado a la branch ”prolijo”. Con cherry-picks apropiados, puedes construir una rama que contenga solo el código permanente, y los commits relacionados juntos en un grupo.
