¿Cuál es la diferencia entre git reset --mixed, --soft, y --hard?

Question

Estoy buscando dividir un compromiso y no estoy seguro de qué opción de reinicio usar.

Estaba mirando la página Can you explain what "git reset" does in plain english?, pero me di cuenta de que realmente no entiendo qué es el índice de git o el área de preparación y por lo tanto las explicaciones no ayudaron.

También los casos de uso para --mixed y --soft me parecen iguales en esa respuesta (cuando se quiere corregir y volver a comprometer). ¿Alguien puede descomponerlo aún más? Me doy cuenta de que --mixed es probablemente la opción, pero quiero saber por qué. Por último, ¿qué pasa con --hard?

¿Alguien puede darme un ejemplo de flujo de trabajo de cómo la selección de las 3 opciones sucedería?

Answer 1

Cuando modifica un archivo en su repositorio, el cambio se inicializa inicialmente. Para comprometerlo, debe organizarlo, es decir, agregarlo al índice, usando git add. Cuando realiza una confirmación, los cambios que se confirman son los que se han agregado al índice.

git reset cambia, como mínimo, a donde apunta la rama actual (HEAD). La diferencia entre --mixed y --soft es si su índice también se modifica o no. Por lo tanto, si estamos en la rama master con esta serie de confirmaciones:

- A - B - C (master) 

HEAD puntos a C y el índice coincide con C.

Cuando ejecute git reset --soft B, master (y por lo tanto HEAD) apunta ahora a B, pero el índice todavía tiene los cambios de C; git status se mostrarán como en etapas. Entonces, si ejecutamos git commit en este punto, obtendremos una nueva confirmación con los mismos cambios que C.

---

bien, así que a partir de aquí de nuevo:

- A - B - C (master) 

Ahora vamos a hacer git reset --mixed B. (Nota: --mixed es la opción predeterminada). Una vez más, master y HEAD apuntan a B, pero esta vez el índice también se modifica para que coincida con B. Si ejecutamos git commit en este punto, nada sucederá ya que el índice coincide con HEAD. Todavía tenemos los cambios en el directorio de trabajo, pero como no están en el índice, git status los muestra como no procesados. Para confirmarlos, debe git add y luego confirmar como de costumbre.

---

Y, por último, --hard es lo mismo que --mixed (que cambia su índice de HEAD y), excepto que --hard también modifica su directorio de trabajo. Si estamos en C y ejecuta git reset --hard B, los cambios agregados en C, así como cualquier cambio no confirmado que tenga, serán eliminados, y los archivos en su copia de trabajo coincidirán con commit B.Dado que puede perder permanentemente los cambios de esta manera, siempre debe ejecutar git status antes de hacer un restablecimiento completo para asegurarse de que su directorio de trabajo está limpio o de que está bien con la pérdida de sus cambios no confirmados.

---

Y, por último, una visualización:

Answer 2

Aquí es una explicación básica para los usuarios TortoiseGit:

git reset --soft y --mixed abandonan sus archivos intactos.

git reset --hard en realidad cambie sus archivos para que coincida con la confirmación que restableció.

En TortoiseGit, el concepto de el índice está muy oculto por la GUI. Cuando modifica un archivo, no tiene que ejecutar git add para agregar el cambio al área/índice de ensayo. Cuando se trata simplemente de modificaciones a archivos existentes que no cambian los nombres de los archivos, git reset --soft y --mixed son lo mismo. Solo notará una diferencia si agregó archivos nuevos o renombrados. En este caso, si ejecuta git reset --mixed, tendrá que volver a agregar su (s) archivo (s) de la lista Archivos no versionados.

Answer 3

Tenga en cuenta que esta es una explicación simplificada que pretende ser un primer paso para comprender esta compleja funcionalidad.

puede ser útil para los estudiantes visuales que quieren visualizar lo que su estado de proyecto parece después de cada uno de estos comandos:

---

Para aquellos que utilizan la terminal con el color encendido (git config --global color.Auto ui):

git reset --soft A y verá B y cosas de C en verde (por etapas y listo para comprometerse)

git reset --mixed A (o git reset A) y verá B y cosas de C en rojo (no escénica y listo para será escenario (verde) y luego comprometido)

git reset --hard A y ya no se verá B y cambios de C en cualquier lugar (será como si nunca hubieran existido)

---

O para aquellos que utilizan un prog GUI ram como 'Torre' o 'SourceTree'

git reset --soft A y verá B y cosas de C en la 'puesta en escena ficheros' zona listo para comprometerse

git reset --mixed A (o git reset A) y verá B y cosas de C en área de los 'ficheros unstaged' listo para ser trasladado a la puesta en escena y luego cometió

git reset --hard A y ya no se vea B y cambios de C en cualquier lugar (será como si nunca hubieran existido)

Answer 4

Una respuesta breve en qué contexto se usan las 3 opciones:

Para mantener los cambios actuales en el código sino para reescribir la historia de la confirmación:

• soft: Puede cometer todo a la vez y crear un nuevo commit con una nueva descripción (si se utiliza torotise git o en la mayoría de las otras GUIs, esta es la que se debe usar, ya que aún se puede marcar qué archivos desea en la confirmación y hacer múltiples confirmaciones de esa manera con diferentes archivos. En SourceTree todos los archivos serían etapas para comprometerse)
• mixed:. Usted tendrá que añadir los archivos individuales de nuevo al índice antes de hacer commit (en SourceTree todos los archivos modificados serían unstaged)

Para en realidad perder sus cambios en el código así:

• hard: usted no sólo reescribir la historia, sino también perderá todos los cambios hasta el punto de restablecer

Answer 5

Antes de entrar en estas tres opciones, uno debe comprender 3 cosas.

1) Historia/HEAD

2) Etapa/índice

3) Directorio de trabajo

--soft reinicio: Historia cambió, cambió CABEZA, Directorio de trabajo no se cambia.

reset --mixed: Historial cambiado, HEAD cambiado, el directorio de trabajo ha cambiado con los datos no registrados.

restablecer --hard: Historial cambiado, HEAD cambiado, el directorio de trabajo se cambia con la pérdida de datos.

Siempre es seguro ir con Git --soft. Uno debe usar otra opción en el requisito complejo.