7.7 Herramientas de Git - Reiniciar Desmitificado

Una manera más fácil de pensar sobre reset y checkout es a través del marco mental de Git como administrador de contenido de tres árboles diferentes. Por “árbol”, aquí realmente queremos decir “colección de archivos”, no específicamente la estructura de datos. (Hay algunos casos donde el índice no funciona exactamente como un árbol, pero para nuestros propósitos es más fácil pensarlo de esta manera por ahora).

Git como sistema maneja y manipula tres árboles en su operación normal:

El objetivo principal de Git es registrar instantáneas de tu proyecto en estados sucesivamente mejores, mediante la manipulación de estos tres árboles.

Visualicemos este proceso: digamos que ingresa en un nuevo directorio con un solo archivo. Llamaremos a esto v1 del archivo, y lo indicaremos en azul. Ahora ejecutamos git init, que creará un repositorio Git con una referencia HEAD que apunta a una rama no nacida (master aún no existe).

En este punto, solo el árbol del Directorio de Trabajo tiene cualquier contenido.

Ahora queremos hacer “commit” a este archivo, por lo que usamos git add para tomar contenido en el directorio de trabajo y copiarlo en el índice.

Luego ejecutamos git commit, que toma los contenidos del índice y los guarda como una instantánea permanente, crea un objeto de “commit” que apunta a esa instantánea y actualiza master para apuntar a ese “commit”.

Si ejecutamos git status, no veremos ningún cambio, porque los tres árboles son iguales.

Ahora queremos hacer un cambio en ese archivo y hacerle un nuevo “commit”. Pasaremos por el mismo proceso; primero, cambiamos el archivo en nuestro directorio de trabajo. Llamemos a esto v2 del archivo, y lo indicamos en rojo.

Si ejecutamos git status ahora, veremos el archivo en rojo como “Changes not staged for commit” porque esa entrada difiere entre el índice y el directorio de trabajo. A continuación, ejecutamos git add para ubicarlo en nuestro índice.

En este punto si ejecutamos git status veremos el archivo en verde debajo de “Changes to be committed” porque el Índice y el HEAD difieren – es decir, nuestro siguiente “commit” propuesto ahora es diferente de nuestro último “commit”. Finalmente, ejecutamos git commit para finalizar el “commit”.

Ahora git status no nos dará salida, porque los tres árboles son iguales nuevamente.

El cambio de ramas o la clonación pasa por un proceso similar. Cuando verifica una rama, eso cambia HEAD para que apunte a la nueva “ref” de la rama, rellena su Índice con la instantánea de esa confirmación, luego copia los contenidos del Índice en tu Directorio de Trabajo.

El comando reset tiene más sentido cuando se ve en este contexto.

A los fines de estos ejemplos, digamos que hemos modificado file.txt de nuevo y le hemos hecho “commit” por tercera vez. Entonces ahora nuestra historia se ve así:

Hablemos ahora sobre lo que reset hace exactamente cuando es llamado. Manipula directamente estos tres árboles de una manera simple y predecible. Hace hasta tres operaciones básicas.

Eso cubre el comportamiento de reset en su forma básica, pero también puedes proporcionarle una ruta para actuar. Si especificas una ruta, reset omitirá el paso 1 y limitará el resto de sus acciones a un archivo o conjunto específico de archivos. Esto realmente tiene sentido – HEAD es solo un puntero, y no se puede apuntar a sólo una parte de un “commit” y otra parte de otro. Pero el Índice y el Directorio de Trabajo pueden actualizarse parcialmente, por lo que el reinicio continúa con los pasos 2 y 3.

Entonces, supongamos que ejecutamos git reset file.txt. Este formulario (ya que no especificó un commit SHA-1 o una rama, y no especificó --soft o --hard) es una abreviatura de git reset --mixed HEAD file.txt, la cual hará:

Por lo tanto, básicamente solo copia archivo.txt de HEAD al Índice.

Esto tiene el efecto práctico de hacer unstaging al archivo. Si miramos el diagrama para ese comando y pensamos en lo que hace git add, son exactamente opuestos.

Esta es la razón por la cual el resultado del comando git status sugiere que ejecute esto para descentralizar un archivo. (Consulte Deshacer un Archivo Preparado para más sobre esto).

Igualmente podríamos no permitir que Git suponga que queríamos “extraer los datos de HEAD” especificando un “commit” específico para extraer esa versión del archivo. Simplemente ejecutaríamos algo como git reset eb43bf file.txt.

Esto efectivamente hace lo mismo que si hubiéramos revertido el contenido del archivo a v1 en el Directorio de Trabajo, ejecutado git add en él, y luego lo revertimos a v3 nuevamente (sin tener que ir a través de todos esos pasos) Si ejecutamos git commit ahora, registrará un cambio que revierte ese archivo de vuelta a v1, aunque nunca más lo volvimos a tener en nuestro Directorio de Trabajo.

También es interesante observar que, como git add, el comando reset aceptará una opción --patch para hacer unstage del contenido en una base hunk-by-hunk. Por lo tanto, puede hacer unstage o revertir el contenido de forma selectiva.

Veamos cómo hacer algo interesante con este poder recién descubierto – aplastando “commits”.

Supongamos que tienes una serie de confirmaciones con mensajes como “oops.”, “WIP” y “se olvidó de este archivo”. Puedes usar reset para aplastarlos rápida y fácilmente en una sola confirmación que lo hace ver realmente inteligente. (Aplastando muestra otra forma de hacerlo, pero en este ejemplo es más simple usar reset.)

Supongamos que tiene un proyecto en el que el primer “commit” tiene un archivo, el segundo “commit” agregó un nuevo archivo y cambió el primero, y el tercer “commit” cambió el primer archivo otra vez. El segundo “commit” fue un trabajo en progreso y quieres aplastarlo.

Puedes ejecutar git reset --soft HEAD~2 para mover la rama HEAD a un “commit” anterior (el primer “commit” que deseas mantener):

Y luego simplemente ejecuta git commit nuevamente:

Ahora puedes ver que el historial alcanzable, la historia que empujarías, ahora parece que tuvo un “commit” con archivo-a.txt v1, luego un segundo que ambos modificaron archivo-a.txt a v3 y agregaron archivo-b.txt. El “commit” con la versión v2 del archivo ya no está en el historial.

Finalmente, puedes preguntarte cuál es la diferencia entre checkout y reset. Al igual que reset, checkout manipula los tres árboles, y es un poco diferente dependiendo de si se le da al comando una ruta de archivo o no.

Esperamos que ahora entiendas y te sientas más cómodo con el comando reset, pero probablemente todavía estés un poco confundido acerca de cómo exactamente difiere de checkout y posiblemente no puedas recordar todas las reglas de las diferentes invocaciones.

Aquí hay una hoja de trucos para cuáles comandos afectan a cuáles árboles. La columna “HEAD” dice “REF” si ese comando mueve la referencia (rama) a la que HEAD apunta, y “HEAD” si se mueve al propio HEAD. Presta especial atención a la columna WD Safe: si dice NO , tómate un segundo para pensar antes de ejecutar ese comando.