lab 17 Quitando Commits de una Ramificación (Branch)
Metas
- Aprender a quitar los Commits más recientes de una ramificación.
El comando revert de la sección previa es un poderoso comando que nos permite deshacer los efectos de cualquier Commit en el repositorio. Sin embrgo, ambos, el Commit original y el Commit “deshecho” están invisibles en el historial de la ramificación (usando el commando git log.
Frecuentemente hacemos un Commit e inmediatamente nos damos cuenta que fue un error. Sería bueno tener un comando “recuperador” que nos permitiera hacer de cuenta que ese commit nunca sucedió. El comando “recuperador” incluso prevendría que el Commit defectuoso se mostrara en el historial que arroja git log. Sería como el Commit defectuoso nunca hubera sucedido.
El comando reset 01
Ya hemos visto el comando reset y lo hemos usado para establecer el área de Staging para que fuera consistente con un Commit en especial (usamos el Commit HEAD en nuestro anterior lab).
Cuando se realiza un Commit referenciado (por ejemplo, un hash, una ramificación o nombre de etiqueta), el comando reset realizará lo siguiente …
- Reescribir la ramificación actual y apuntarlo a un Commit en específico
- Opcionalmente reestablecer el área de Staging para coincidir con el Commit especificado
- Opcionalmente reestablecer el directorio de trabajo para coincidir con el Commit especificado
Revisar nuestro historial 02
Hagamos una revisión rápida de nuestro historial de Commits.
Ejecute:
git hist
Salida:
$ git hist * 9ad227a 2012-03-06 | Revert "Oops, we didn't want this commit" (HEAD, master) [Jim Weirich] * d20d016 2012-03-06 | Oops, we didn't want this commit [Jim Weirich] * 4054321 2012-03-06 | Added a comment (v1) [Jim Weirich] * 1b754e9 2012-03-06 | Added a default value (v1-beta) [Jim Weirich] * 3053491 2012-03-06 | Using ARGV [Jim Weirich] * 3cbf83b 2012-03-06 | First Commit [Jim Weirich]
Vemos que tenemos un Commit “Oops” y “Revert Oops” en los últimos dos Commits hechos en esta ramificación. Vamos a quitarlos usando reset.
Primero, marquemos esta Ramificación 03
Pero antes de quitar los Commits, marquemos el último Commit con una etiqueta, así podremos buscarlo de nuevo.
Ejecute:
git tag oops
Reestablecer el repositorio a como se encontraba antes de Oops 04
Al ver el historial (arriba), podemos ver que el Commit etiquetado como ‘v1’ es el que se encuentra justo antes del mal comentario. Reestablezcamos el branch a ese punto. Debido a que el Branch está etiquetado , podemos usar el nombre de la etiqueta en el comando reset (si no fue etiquetado, podemos usar su hash).
Ejecute:
git reset --hard v1 git hist
Salida:
$ git reset --hard v1 HEAD is now at 4054321 Added a comment $ git hist * 4054321 2012-03-06 | Added a comment (HEAD, v1, master) [Jim Weirich] * 1b754e9 2012-03-06 | Added a default value (v1-beta) [Jim Weirich] * 3053491 2012-03-06 | Using ARGV [Jim Weirich] * 3cbf83b 2012-03-06 | First Commit [Jim Weirich]
Nuestro branch principal ahora apunta al Commit v1 y el commit "Oops" y "Revert Oops commit" no están más en la rama. El parámetro --hard indica que el directorio de trabajo debe ser actualizado para ser consistente con la nueva cabeza del branch.
Nada se Pierde 05
Pero ¿qué les pasó a los malos Commits? Resulta que esos Commits están aún en el repositorio. De hecho, aún podemos referenciarlos. Recuerda que al inicio de este lab etiquetamos el Commit con “oops”. Veamos en todos los Commits.
Ejecute:
git hist --all
Salida:
$ git hist --all * 9ad227a 2012-03-06 | Revert "Oops, we didn't want this commit" (oops) [Jim Weirich] * d20d016 2012-03-06 | Oops, we didn't want this commit [Jim Weirich] * 4054321 2012-03-06 | Added a comment (HEAD, v1, master) [Jim Weirich] * 1b754e9 2012-03-06 | Added a default value (v1-beta) [Jim Weirich] * 3053491 2012-03-06 | Using ARGV [Jim Weirich] * 3cbf83b 2012-03-06 | First Commit [Jim Weirich]
Aquí vemos que los malos Commits no han desaparecido, aún están en el repository. Lo que sucede es que sólo no están listados en el branch principal. Si no los hemos etiquetado, seguirían aún en el repositorio, pero no habría forma de referenciarlos más que usando los valores de hash. Los Commits que no tienen referencia quedan en el repositorio hasta que el sistema ejecuta el software de recolección de basura.
Peligros del Reset 06
Los Resets en ramificaciones locales son generalmente seguros. Cualquier accidente puede ser recuperado con sólo reestablecerlo al Commit deseado.
Sin embargo, si la ramificación está compartido en repositorios remotos, puede confundir a otros usuarios que comparten el branch.