Download Git Magic

Transcript
Capítulo 4. Magia Con Los Branches
Mencionamos este comando en un capítulo anterior, cuando discutíamos sobre cargar estados antiguos.
Al fin podemos contar toda la historia:los archivos cambian al estado pedido, pero debemos dejar la
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.
4.3. Arreglos Rápidos
Estás en medio de algo cuando te piden que dejes todo y soluciones un bug recién descubierto:
$ git commit -a
$ git checkout -b arreglos SHA1_HASH
Luego, una vez que solucionaste el bug:
$ git commit -a -m "Bug arreglado"
$ git push # al repositorio central
$ git checkout master
y continúa con el trabajo en tu tarea original.
4.4. Flujo De Trabajo Ininterrumpido
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,
15