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 Papel del Reinicio

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í: