Estas felizmente trabajando en algo y los cambios en esos ficheros ya los ves bien; no quieres verlos al hacer git diff porque planeas trabajar en otros ficheros y los cambios a los primeros te distraen.

Alguien te pide incorporar, y parece que vale la pena fusionar esos cambios.

Sin embargo, ya ensuciaste el índice (es decir, tu índice no coincide con la HEAD de la confirmación). Pero sabes que la incorporación que vas a hacer no afecta frotz.c o filtre.c, así que reviertes los cambios al índice para esos dos ficheros. Tus cambios en el árbol de trabajo permanecen ahí.

Entonces puedes incorporar y fusionar, manteniendo aún los cambios en frotz.c y filfre.c en el árbol de trabajo.

Esto se hace mas frecuentemente cuando recuerdas que esta incompleto lo que acabas de confirmar, o escribiste mal tu mensaje de confirmación, o ambos. Deja el árbol de trabajo como estaba antes del "reset".

Hacer correcciones a ficheros del árbol de trabajo.

"reset" copia la cabeza anterior a .git/ORIG_HEAD; rehace la confirmación comenzando con su mensaje de registro. Si no necesitas editar mas el mensaje, simplemente puedes dar la opción -C.

Has hecho algunas confirmaciones, pero te das cuenta que fue prematuro hacerlo en la rama master. Quieres continuar puliéndolas en una rama tópica, entonces creas la rama topic/wip a partir de la HEAD actual.

Regresas la rama master para deshacerte de esas tres confirmaciones.

Cambias a la rama topic/wip y sigues trabajando.

Las últimas tres confirmaciones (HEAD, HEAD^ y HEAD~2) estuvieron mal y no quieres ni siquiera verlas otra vez. No hagas esto si ya le has dado esas confirmaciones a alguien mas. (Ver la sección "Recuperándose de un rebase río arriba" en git-rebase[1] para las implicaciones de hacerlo.)

El intento de actualizar desde el origen resultó en un montón de conflictos; y como no estabas listo para pasar mucho tiempo fusionando en el momento decides hacerlo después.

"pull" no confirmó la fusión, entonces git reset --hard que es un sinónimo de git reset --hard HEAD limpia el desastre partiendo del fichero del índice y el árbol de trabajo.

Fusiona una rama tópica en el rama actual, lo que resulta en un avance rápido.

Pero decidiste que la rama tópica aún no esta lista para consumo público. "pull" o "merge" siempre dejan la punta original de la rama actual en ORIG_HEAD, de tal manera que restableciéndola duramente te trae de vuelta tu fichero del índice y el árbol de trabajo en ese estado, y restablece la punta de la rama a esa confirmación.

Incluso si tuvieras modificaciones locales en tu árbol de trabajo, puedes hacer con seguridad git pull cuando sabes que los cambios en la otra rama no se traslapan con los tuyos.

Después de inspeccionar el resultado de la fusión, podrías encontrar que el cambio en la otra rama es insatisfactorio. Ejecutar git reset --hard ORIG_HEAD te regresará a donde estabas, pero descartará tus cambios locales, lo cual no quieres. git reset --merge mantiene tus cambios locales.

Esta confirmación explotará, así que un mensaje de desecho no va mal.

Esto quita la confirmación WIP del historial de confirmaciones, y establece tu árbol de trabajo al estado justo antes de que hicieras esa instantánea.

En este punto el fichero del índice aún tiene todos los cambios de WIP que confirmaste como snapshot WIP. Esto actualiza el índice para mostrar tus ficheros de WIP como no confirmados.

Esto quita el fichero del índice mientras lo mantiene en el directorio de trabajo.

Esto confirma todos los cambios en el índice.

Agrega el archivo de nuevo al índice.

Esto confirma tus primeras ediciones en branch1.

En un mundo ideal, al querer crear branch2 y cambiar a ella podrías haber notado que la confirmación anterior no pertenece al nuevo tópico (es decir, git switch -c branch2 start), pero nadie es perfecto.

Pero ahora puedes usar reset --keep para quitar la confirmación no deseada después de cambiar a branch2.

Primero, restablece el historial una confirmación hacia atrás para eliminar la confirmación original, pero dejando el árbol de trabajo con todos sus cambios. -N asegura que cualquier fichero nuevo agregado con HEAD quede marcado para que git add -p los encuentre.

Después, interactivamente seleccionamos los pedazos de diferencia a agregar usando la prestación git add -p. Esto te preguntará en secuencia por cada pedazo de diferencia y podrás simplemente usar instrucciones como "si, incluirlo", "no incluirlo" o la muy poderosa "editar".

Una vez satisfecho con los pedazos que quieres incluir, deberías verificar lo que se ha preparado para la primer confirmación usando git diff --cached. Esto muestra todos los cambios que se han movido al índice y serán confirmados.

Lo siguiente, confirmar los cambios almacenados en el índice. La opción -c especifica pre-llenar el mensaje de confirmación a partir del mensaje original que iniciaste en la primer confirmación. Esto ayuda a evitar volver a teclearlo. HEAD@{1} es una notación especial para referirse a la confirmación donde estaba HEAD antes de la confirmación original restablecida (hace 1 cambio). Ver git-reflog[1] para mas detalles. También puedes usar cualquier otra referencia de confirmación válida.

Puedes repetir los pasos 2 a 4 varias veces para despedazar el código original en cualquier número de confirmaciones.

Ahora que has dividido varios cambios en sus respectivas confirmaciones, puede que ya no uses el modo de parche de git add, con tal de seleccionar los cambios sin confirmar restantes.

Una vez mas, revisa que lo incluido es lo que quieres. También querrías verificar que git diff no muestre algún cambio remanente a ser confirmado después.

Y por último, crear la confirmación final.