ℹ️ Skipped - page is already crawled
| Filter | Status | Condition | Details |
|---|---|---|---|
| HTTP status | PASS | download_http_code = 200 | HTTP 200 |
| Age cutoff | PASS | download_stamp > now() - 6 MONTH | 0.4 months ago |
| History drop | PASS | isNull(history_drop_reason) | No drop reason |
| Spam/ban | PASS | fh_dont_index != 1 AND ml_spam_score = 0 | ml_spam_score=0 |
| Canonical | PASS | meta_canonical IS NULL OR = '' OR = src_unparsed | Not set |
| Property | Value |
|---|---|
| URL | https://www.atlassian.com/es/git/tutorials/undoing-changes/git-reset |
| Last Crawled | 2026-04-01 14:50:43 (12 days ago) |
| First Indexed | 2019-07-21 06:59:19 (6 years ago) |
| HTTP Status Code | 200 |
| Meta Title | Git reset | Tutorial de Atlassian sobre Git |
| Meta Description | git reset es un comando potente que sirve para deshacer los cambios locales en el estado de un repositorio de Git. Descubre las tres formas principales de invocarlo en este artículo. |
| Meta Canonical | null |
| Boilerpipe Text | El comando
git reset
es una herramienta compleja y versátil para deshacer cambios. Se invoca principalmente de tres formas distintas, que se corresponden con los argumentos de líneas de comandos
--soft, --mixed y --hard
. Cada uno de los tres argumentos se corresponde con los tres mecanismos de gestión de estados internos de Git: el árbol de confirmaciones (
HEAD
), el índice del entorno de ensayo y el directorio de trabajo.
Git reset y los tres árboles de Git
Para entender correctamente cómo utilizar
git reset
, primero tenemos que entender los sistemas de gestión de estados internos de Git. A veces, a estos mecanismos se les llama los "tres árboles" de Git. Puede que este nombre sea poco apropiado, ya que no son estrictamente estructuras de datos tradicionales en forma de árbol. Sin embargo, son estructuras de datos de nodos y basadas en punteros que Git utiliza para monitorizar un cronograma de ediciones. La mejor manera de demostrar estos mecanismos es crear un conjunto de cambios en un repositorio y seguirlo a lo largo de los tres árboles.
Para empezar, crearemos un nuevo repositorio con los siguientes comandos:
$ mkdir git_reset_test
$ cd git_reset_test/
$ git init .
Initialized empty Git repository in /git_reset_test/.git/
$ touch reset_lifecycle_file
$ git add reset_lifecycle_file
$ git commit -m"initial commit"
[main (root-commit) d386d86] initial commit
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 reset_lifecycle_file
El código de ejemplo anterior crea un nuevo repositorio de Git con un único archivo vacío:
reset_lifecycle_file
. En este punto, el repositorio de ejemplo tiene una única confirmación (
d386d86
) de añadir
reset_lifecycle_file
.
El directorio de trabajo
El primer árbol que examinaremos es "el directorio de trabajo". Este árbol está sincronizado con el sistema de archivos local y representa los cambios inmediatos que se realizan en el contenido de los archivos y los directorios.
$ echo 'hello git reset' > reset_lifecycle_file
$ git status
On branch main
Changes not staged for commit:
(use "git add ..." to update what will be committed)
(use "git checkout -- ..." to discard changes in working directory)
modified: reset_lifecycle_file
En nuestro repositorio de ejemplo, modificamos y añadimos contenido a
reset_lifecycle_file
. Al invocar
git status
, se muestra que Git está al corriente de los cambios en el archivo. En ese momento estos cambios forman parte del primer árbol: "el directorio de trabajo".
git status
puede utilizarse para mostrar los cambios en el directorio de trabajo. Se mostrarán en rojo con el prefijo "modified".
Índice del entorno de ensayo
El siguiente es el árbol del "índice del entorno de ensayo". Este árbol monitoriza los cambios en el directorio de trabajo, que se han aplicado con
git add
, para que se almacenen en la siguiente confirmación. Este árbol es un complejo mecanismo de almacenamiento en caché interno. Por lo general, Git intenta ocultar al usuario los pormenores de la implementación del índice del entorno de ensayo.
Para ver con exactitud el estado del índice del entorno de ensayo, debemos utilizar un comando de Git menos conocido:
git ls-files
. El comando
git ls-files
es, básicamente, una utilidad de depuración que sirve para inspeccionar el estado del árbol del índice del entorno de ensayo.
git ls-files -s
100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 0 reset_lifecycle_file
Aquí hemos ejecutado
git ls-files
con la opción
-s
o
--stage
. Sin la opción
-s
, el resultado de
git ls-files
es simplemente una lista de nombres de archivos y rutas que forman parte del índice en ese momento. La opción
-s
muestra metadatos adicionales de los archivos del índice del entorno de ensayo. Estos metadatos son los bits de modo, el nombre de objeto y el número de entorno del contenido preparado. A nosotros nos interesa el nombre de objeto, el segundo valor (
d7d77c1b04b5edd5acfc85de0b592449e5303770
). Se trata de un hash SHA-1 de objeto de Git estándar. Es un hash del contenido de los archivos. El historial de confirmaciones almacena sus propios SHA de objeto para identificar los punteros de confirmaciones y de referencias, y el índice del entorno de ensayo tiene sus propios SHA de objeto para monitorizar versiones de archivos en el índice.
A continuación, pasaremos el archivo
reset_lifecycle_file
modificado al índice del entorno de ensayo.
$ git add reset_lifecycle_file
$ git status
On branch main Changes to be committed:
(use "git reset HEAD ..." to unstage)
modified: reset_lifecycle_file
Aquí hemos invocado
git add reset_lifecycle_file
que añade el archivo al índice del entorno de ensayo. Al invocar
git status
, ahora aparece
reset_lifecycle_file
en verde debajo de "Changes to be committed". Conviene resaltar que
git status
no es una representación verdadera del índice del entorno de ensayo. El resultado del comando
git status
muestra los cambios entre el historial de confirmaciones y el índice del entorno de ensayo. Llegados a este punto, vamos a examinar el contenido del índice del entorno de ensayo.
$ git ls-files -s 100644 d7d77c1b04b5edd5acfc85de0b592449e5303770 0 reset_lifecycle_file
Podemos ver que el SHA de objeto de
reset_lifecycle_file
se ha actualizado de
e69de29bb2d1d6434b8b29ae775ad8c2e48c5391
a
d7d77c1b04b5edd5acfc85de0b592449e5303770
.
Historial de confirmaciones
El último árbol es el historial de confirmaciones. El comando
git commit
añade cambios a una instantánea permanente que reside en el historial de confirmaciones. Esta instantánea también incluye el estado que tenía el índice del entorno de ensayo en el momento de efectuar la confirmación.
$ git commit -am"update content of reset_lifecycle_file"
[main dc67808] update content of reset_lifecycle_file
1 file changed, 1 insertion(+)
$ git status
On branch main
nothing to commit, working tree clean
Aquí hemos creado una nueva confirmación con el mensaje
"update content of resetlifecyclefile"
. El conjunto de cambios se ha añadido al historial de confirmaciones. Al invocar
git status
en este momento, se muestra que no hay cambios pendientes en ninguno de los árboles. Al ejecutar
git log
se mostrará el historial de confirmaciones. Ahora que hemos seguido la trayectoria de este conjunto de cambios por los tres árboles, podemos empezar a utilizar
git reset
.
Funcionamiento
A nivel superficial,
git reset
tiene un comportamiento parecido a
git checkout
. Mientras que
git checkout
solo opera en el puntero de referencia
HEAD
,
git reset
moverá el puntero de referencia
HEAD
y el puntero de referencia de la rama actual. Para demostrar mejor este comportamiento, vamos a analizar el siguiente ejemplo:
En este ejemplo se muestra una secuencia de confirmaciones en la rama
main
. La referencia
HEAD
y la referencia de la rama
main
en estos momentos apuntan a la confirmación d. Ahora vamos a ejecutar y a comparar tanto
git checkout b
como
git reset b
.
git checkout b
Con
git checkout
, la referencia
main
sigue apuntando a
d
. La referencia
HEAD
se ha movido y ahora apunta a la confirmación
b
. Ahora el repositorio se encuentra en un estado de "
HEAD
desasociado".
git reset b
En comparación,
git reset
mueve tanto las referencias de
HEAD
como las de la rama a la confirmación especificada.
Además de actualizar los punteros de referencia de las confirmaciones,
git reset
modificará el estado de los tres árboles. La modificación del puntero de referencia sucede siempre y es una actualización del tercer árbol, el árbol de confirmaciones. Los argumentos de las líneas de comandos
--soft, --mixed
y
--hard
indican cómo modificar los árboles del índice del entorno de ensayo y del directorio de trabajo.
Opciones principales
La invocación predeterminada de
git reset
tiene argumentos implícitos de
--mixed
y
HEAD
. Esto significa que ejecutar
git reset
equivale a ejecutar
git reset --mixed HEAD
. De esta forma,
HEAD
es la confirmación especificada. En vez de
HEAD
, se puede usar cualquier hash de confirmación SHA-1 de Git.
'--hard
Esta es la opción más directa, PELIGROSA y habitual. Cuando se pasa
--hard
, los punteros de referencia del historial de confirmaciones se actualizan a la confirmación especificada. A continuación, el índice del entorno de ensayo y el directorio de trabajo se restablecen para reflejar la confirmación especificada. Todos los cambios pendientes anteriores del índice del entorno de ensayo y del directorio de trabajo se restablecen para reflejar el estado del árbol de confirmaciones. Esto significa que se perderá cualquier trabajo pendiente que haya quedado en el índice del entorno de ensayo y en el directorio de trabajo.
Para demostrarlo, continuemos con el repositorio de ejemplo de los tres árboles que hemos visto antes. En primer lugar, hagamos unas cuantas modificaciones en el repositorio. Ejecuta los siguientes comandos en el repositorio de ejemplo:
$ echo 'new file content' > new_file
$ git add new_file
$ echo 'changed content' >> reset_lifecycle_file
Estos comandos han creado un nuevo archivo llamado
new_file
y lo han añadido al repositorio. Además, se modificará el contenido de
reset_lifecycle_file
. Ahora que se han aplicado estos cambios, examinemos el estado del repositorio usando
git status
.
$ git status
On branch main
Changes to be committed:
(use "git reset HEAD ..." to unstage)
new file: new_file
Changes not staged for commit:
(use "git add ..." to update what will be committed)
(use "git checkout -- ..." to discard changes in working directory)
modified: reset_lifecycle_file
Aquí hemos invocado
git add reset_lifecycle_file
que añade el archivo al índice del entorno de ensayo. Al invocar
git status
, ahora aparece
reset_lifecycle_file
en verde debajo de "Changes to be committed". Conviene resaltar que
git status
no es una representación verdadera del índice del entorno de ensayo. El resultado del comando
git status
muestra los cambios entre el historial de confirmaciones y el índice del entorno de ensayo. Llegados a este punto, vamos a examinar el contenido del índice del entorno de ensayo.
$ git ls-files -s
100644 8e66654a5477b1bf4765946147c49509a431f963 0 new_file
100644 d7d77c1b04b5edd5acfc85de0b592449e5303770 0 reset_lifecycle_file
Podemos ver que
new_file
se ha añadido al índice. Hemos efectuado modificaciones en
reset_lifecycle_file
, pero el SHA del índice del entorno de ensayo (
d7d77c1b04b5edd5acfc85de0b592449e5303770
) sigue siendo el mismo. Este es un comportamiento previsto, ya que no se ha usado
git add
para aplicar estos cambios en el índice del entorno de ensayo. Estos cambios existen en el directorio de trabajo.
Ahora vamos a ejecutar un comando
git reset --hard
y a examinar el nuevo estado del repositorio.
$ git reset --hard
HEAD is now at dc67808 update content of reset_lifecycle_file
$ git status
On branch main
nothing to commit, working tree clean
$ git ls-files -s
100644 d7d77c1b04b5edd5acfc85de0b592449e5303770 0 reset_lifecycle_file
Aquí hemos ejecutado un "hard reset" utilizando la opción
--hard
. Git muestra el resultado indicando que
HEAD
apunta a la última confirmación
dc67808
. A continuación, comprobamos el estado del repositorio con
git status
. Git indica que no hay cambios pendientes. Examinamos también el estado del índice del entorno de ensayo y vemos que se ha restablecido a un punto anterior a que se añadiera
new_file
. Nuestras modificaciones en
reset_lifecycle_file
y la adición de
new_file
se han destruido. Esta pérdida de datos no se puede deshacer. Es esencial que tomemos buena nota de ello.
'--mixed
Este es el modo de funcionamiento predeterminado. Se actualizan los punteros de referencia. El índice del entorno de ensayo se restablece al estado de la confirmación especificada. Todos los cambios que se hayan deshecho en el índice del entorno de ensayo se mueven al directorio de trabajo. Vamos a continuar.
$ echo 'new file content' > new_file
$ git add new_file
$ echo 'append content' >> reset_lifecycle_file
$ git add reset_lifecycle_file
$ git status
On branch main
Changes to be committed:
(use "git reset HEAD ..." to unstage)
new file: new_file
modified: reset_lifecycle_file
$ git ls-files -s
100644 8e66654a5477b1bf4765946147c49509a431f963 0 new_file
100644 7ab362db063f9e9426901092c00a3394b4bec53d 0 reset_lifecycle_file
En el ejemplo anterior, hemos hecho unas cuantas modificaciones en el repositorio. De nuevo, hemos añadido un
new_file
y modificado el contenido de
reset_lifecycle_file
. A continuación, estos cambios se aplican al índice del entorno de ensayo con
git add
. Con el repositorio en este estado, ejecutaremos ahora el restablecimiento.
$ git reset --mixed
$ git status
On branch main
Changes not staged for commit:
(use "git add ..." to update what will be committed)
(use "git checkout -- ..." to discard changes in working directory)
modified: reset_lifecycle_file
Untracked files:
(use "git add ..." to include in what will be committed)
new_file
no changes added to commit (use "git add" and/or "git commit -a")
$ git ls-files -s
100644 d7d77c1b04b5edd5acfc85de0b592449e5303770 0 reset_lifecycle_file
Aquí hemos ejecutado un "mixed reset". Para que quede claro,
--mixed
es el modo predeterminado y surte el mismo efecto que ejecutar
git reset
. Al examinar el resultado de
git status
y
git ls-files
, se ve que el índice del entorno de ensayo se ha restablecido a un estado en el que
reset_lifecycle_file
es el único archivo del índice. El SHA de objeto de
reset_lifecycle_file
se ha restablecido a la versión anterior.
Lo importante que debemos destacar aquí es que
git status
nos muestra que hay modificaciones en
reset_lifecycle_file
y que hay un archivo sin seguimiento:
new_file
. Este es el comportamiento
--mixed
explícito. Se ha restablecido el índice del entorno de ensayo y se han movido los cambios pendientes al directorio de trabajo. Solo tienes que compararlo con el caso del
--hard
reset, en el que se restablecieron tanto el índice del entorno de ensayo como el directorio de trabajo, lo que hizo que se perdieran estas actualizaciones.
'--soft
Cuando se pasa el argumento
--soft
, se actualizan los punteros de referencia y el restablecimiento se detiene ahí. El índice del entorno de ensayo y el directorio de trabajo permanecen intactos. Puede ser difícil demostrar claramente este comportamiento. Vamos a continuar con nuestro repositorio demo y a prepararlo para un soft reset.
$ git add reset_lifecycle_file
$ git ls-files -s
100644 67cc52710639e5da6b515416fd779d0741e3762e 0 reset_lifecycle_file
$ git status
On branch main
Changes to be committed:
(use "git reset HEAD ..." to unstage)
modified: reset_lifecycle_file
Untracked files:
(use "git add ..." to include in what will be committed)
new_file
Aquí hemos utilizado otra vez
git add
para pasar el
reset_lifecycle_file
modificado al índice del entorno de ensayo. Confirmamos que el índice se ha actualizado con el resultado de
git ls-files
. El resultado de
git status
ahora muestra "Changes to be committed" en verde. El
new_file
de nuestros ejemplos anteriores está flotando por el directorio de trabajo como un archivo sin seguimiento. Vamos a ejecutar rápidamente
rm new_file
para eliminar el archivo, puesto que no lo necesitaremos para los siguientes ejemplos.
Con el repositorio en este estado, ejecutaremos ahora un restablecimiento parcial (soft reset).
$ git reset --soft
$ git status
On branch main
Changes to be committed:
(use "git reset HEAD ..." to unstage)
modified: reset_lifecycle_file
$ git ls-files -s
100644 67cc52710639e5da6b515416fd779d0741e3762e 0 reset_lifecycle_file
Hemos ejecutado un "soft reset". Al examinar el estado del repositorio con
git status
y
git ls-files
, se muestra que no ha cambiado nada. Es un comportamiento esperado. Un soft reset solo restablecerá el historial de confirmaciones. De manera predeterminada,
git reset
se invoca con
HEAD
como la confirmación objetivo. Como nuestro historial de confirmaciones ya se encontraba en
HEAD
y restablecemos implícitamente a
HEAD
, no ha ocurrido nada en realidad.
Para entender y utilizar mejor
--soft
, necesitamos una confirmación objetivo que no sea
HEAD
. Tenemos a
reset_lifecycle_file
en espera en el índice del entorno de ensayo. Vamos a crear una nueva confirmación.
$ git commit -m"prepend content to reset_lifecycle_file"
En este punto, nuestro repositorio debería tener tres confirmaciones. Retrocederemos en el tiempo hasta la primera de ellas. Para ello, necesitaremos el ID de la primera confirmación. Se puede saber viendo el resultado desde
git log
.
$ git log
commit 62e793f6941c7e0d4ad9a1345a175fe8f45cb9df
Author: bitbucket
Date: Fri Dec 1 15:03:07 2017 -0800
prepend content to reset_lifecycle_file
commit dc67808a6da9f0dec51ed16d3d8823f28e1a72a
Author: bitbucket
Date: Fri Dec 1 10:21:57 2017 -0800
update content of reset_lifecycle_file
commit 780411da3b47117270c0e3a8d5dcfd11d28d04a4
Author: bitbucket
Date: Thu Nov 30 16:50:39 2017 -0800
initial commit
Ten en cuenta que los ID del historial de confirmaciones serán únicos en cada sistema. Esto significa que los ID de confirmación de este ejemplo serán diferentes de los que veas en tu dispositivo. El ID de confirmación que nos interesa para este ejemplo es
780411da3b47117270c0e3a8d5dcfd11d28d04a4
. Es el ID que corresponde a la confirmación inicial (initial commit). Una vez que hayamos localizado este ID, lo utilizaremos como objetivo de nuestro soft reset.
Antes de retroceder en el tiempo, vamos a comprobar primero el estado actual del repositorio.
$ git status && git ls-files -s
On branch main
nothing to commit, working tree clean
100644 67cc52710639e5da6b515416fd779d0741e3762e 0 reset_lifecycle_file
Aquí ejecutamos un comando combinado de
git status y git ls-files -s
que nos muestra que hay cambios pendientes en el repositorio y que
reset_lifecycle_file
del índice del entorno de ensayo se encuentra en una versión de
67cc52710639e5da6b515416fd779d0741e3762e
. Teniendo esto en cuenta, vamos a ejecutar un soft reset a nuestra primera confirmación.
$git reset --soft 780411da3b47117270c0e3a8d5dcfd11d28d04a4
$ git status && git ls-files -s
On branch main
Changes to be committed:
(use "git reset HEAD ..." to unstage)
modified: reset_lifecycle_file
100644 67cc52710639e5da6b515416fd779d0741e3762e 0 reset_lifecycle_file
El código anterior ejecuta un "soft reset" y también invoca el comando combinado
git status
y
git ls-files
, que muestra el resultado del estado del repositorio. Podemos examinar el resultado del estado del repositorio y sacar algunas observaciones interesantes. En primer lugar,
git status
indica que hay modificaciones en
reset_lifecycle_file
y las resalta indicando que son cambios preparados para la siguiente confirmación. En segundo lugar, la información de
git ls-files
indica que el índice del entorno de ensayo no ha cambiado y conserva el SHA zero-width 67cc52710639e5da6b515416fd779d0741e3762e que teníamos antes.
Para explicar mejor lo que ha ocurrido en este restablecimiento, vamos a examinar el
git log
:
$ git log commit 780411da3b47117270c0e3a8d5dcfd11d28d04a4 Author: bitbucket Date: Thu Nov 30 16:50:39 2017 -0800 initial commit
El resultado del registro ahora muestra que hay una única confirmación en el historial de confirmaciones. Esto ayuda a ilustrar claramente qué ha hecho
--soft
. Como sucede en todas las invocaciones de
git reset
, lo primero que hace el restablecimiento es restablecer el árbol de confirmaciones. Los dos ejemplos anteriores con
--hard
y
--mixed
han apuntado a
HEAD
y no han hecho que el árbol de confirmaciones retroceda en el tiempo. Durante un soft reset, esto es lo único que sucede.
Entonces, podríamos preguntarnos por qué
git status
indica que hay archivos modificados.
--soft
no toca el índice del entorno de ensayo, por lo que las actualizaciones de este nos han acompañado en el tiempo a lo largo del historial de confirmaciones. Podemos confirmarlo con el resultado de
git ls-files -s
, que muestra que no ha cambiado el SHA de
reset_lifecycle_file
. Como recordatorio,
git status
no muestra el estado de "los tres árboles", sino que, en esencia, muestra una comparación entre ellos. En este caso, muestra que el índice del entorno de ensayo va por delante de los cambios del historial de confirmaciones como si ya los hubiéramos preparado.
Diferencia entre restablecer y revertir
Si
git revert
es una forma "segura" de deshacer los cambios, podríamos considerar
git reset
como el método peligroso. Corremos el riesgo real de perder trabajo con
git reset
.
git reset
nunca eliminará una confirmación. Sin embargo, las confirmaciones pueden quedarse "huérfanas", es decir, sin una ruta directa desde una referencia para acceder a ellas. Normalmente estas confirmaciones huérfanas pueden localizarse y restaurarse utilizando
git reflog
. Git eliminará para siempre las confirmaciones huérfanas tras ejecutar el recolector de basura interno. De manera predeterminada, Git está configurado para ejecutar el recolector de basura cada 30 días. El historial de confirmaciones es uno de los "tres árboles de Git"; los otros dos, el índice del entorno de ensayo y el directorio de trabajo, no son tan permanentes como las confirmaciones. Se debe tener cuidado al utilizar esta herramienta, ya que es uno de los únicos comandos de Git que puede hacerte perder el trabajo realizado.
Mientras que la reversión se ha diseñado para deshacer de forma segura una confirmación pública,
git reset
se ha diseñado para deshacer los cambios locales en el índice del entorno de ensayo y el directorio de trabajo. Dado que sus objetivos son diferentes, los dos comandos se implementan de forma distinta: el restablecimiento elimina por completo un conjunto de cambios, mientras que la reversión conserva el conjunto de cambios original y utiliza una nueva confirmación para aplicar la acción de deshacer.
No restablezcas el historial público
No deberías utilizar nunca
git reset <commit>
si se ha enviado alguna instantánea posterior a
<commit>
a un repositorio público. Después de publicar una confirmación, tienes que dar por sentado que el resto de los desarrolladores dependen de ella.
Eliminar una confirmación que otros miembros del equipo han seguido desarrollando supone un problema grave para la colaboración. Cuando intenten sincronizarse con tu repositorio, parecerá que un pedazo del historial del proyecto ha desaparecido repentinamente. En la secuencia que aparece abajo se muestra lo que ocurre cuando intentas restablecer una confirmación pública. La rama
origin/main
es la versión de tu rama
main
local del repositorio central.
En cuanto añadas nuevas confirmaciones tras el restablecimiento, Git creerá que tu historial local se ha desviado de
origin/main
, y es probable que la confirmación de fusión necesaria para sincronizar tus repositorios confunda y frustre a tu equipo.
Lo importante es que te asegures de que estás utilizando
git reset <commit>
en un experimento local que salió mal, no en cambios publicados. Si tienes que arreglar una confirmación pública, el comando
git revert
se ha diseñado específicamente para este fin.
Ejemplos
git reset <file>
Elimina el archivo especificado del entorno de ensayo, pero el directorio de trabajo se mantiene intacto. Deshace la preparación de un archivo sin sobrescribir ninguno de los cambios.
git reset
Restablece el entorno de ensayo para que refleje la confirmación más reciente, pero el directorio de trabajo se mantiene intacto. Deshace la preparación de todos los archivos sin sobrescribir ninguno de los cambios, lo que te da la oportunidad de volver a compilar la instantánea preparada desde cero.
git reset --hard
Restablece el entorno de ensayo y el directorio de trabajo para que reflejen la confirmación más reciente. Además de deshacer la preparación de los cambios, el indicador
--hard
le indica a Git que sobrescriba todos los cambios en el directorio de trabajo también. Dicho de otra manera: borra todos los cambios no confirmados, así que asegúrate de que realmente quieres descartar tus desarrollos locales antes de utilizarlo.
git reset
Retrocede el extremo de la rama actual a
commit
, restablece el entorno de ensayo para que coincida, pero no toques el directorio de trabajo. Todos los cambios realizados desde
<commit>
se encontrarán en el directorio de trabajo, que te permite volver a confirmar el historial del proyecto utilizando instantáneas más limpias y más atómicas.
git reset --hard
Retrocede el extremo de la rama actual a
<commit>
y restablece tanto el entorno de ensayo como el directorio de trabajo para que coincidan. Esta acción elimina no solo los cambios no confirmados, sino también todas las confirmaciones posteriores.
Cómo deshacer la preparación de un archivo
El comando
git reset
suele aparecer mientras se prepara la instantánea preparada. En el siguiente ejemplo, se da por supuesto que tienes dos archivos llamados
hello.py
y
main.py
que ya has añadido al repositorio.
# Edit both hello.py and main.py
# Stage everything in the current directory
git add .
# Realize that the changes in hello.py and main.py
# should be committed in different snapshots
# Unstage main.py
git reset main.py
# Commit only hello.py
git commit -m "Make some changes to hello.py"
# Commit main.py in a separate snapshot
git add main.py
git commit -m "Edit main.py"
Como puedes ver,
git reset
te ayudar a mantener tus confirmaciones con un enfoque muy claro al permitirte deshacer la preparación de los cambios que no están relacionados con la siguiente confirmación.
Eliminación de las confirmaciones locales
El siguiente ejemplo muestra un caso práctico más avanzado. Demuestra qué sucede cuando has estado trabajando en un nuevo experimento durante un tiempo, pero decides descartarlo por completo tras confirmar unas cuantas instantáneas.
# Create a new file called `foo.py` and add some code to it
# Commit it to the project history
git add foo.py
git commit -m "Start developing a crazy feature"
# Edit `foo.py` again and change some other tracked files, too
# Commit another snapshot
git commit -a -m "Continue my crazy feature"
# Decide to scrap the feature and remove the associated commits
git reset --hard HEAD~2
El comando
git reset HEAD~2
retrocede la rama actual dos confirmaciones, con lo que se elimina de forma eficaz las dos instantáneas que acabamos de crear a partir del historial del proyecto. Recuerda que este tipo de restablecimiento solo debe utilizarse en las confirmaciones no publicadas. No hagas nunca la operación anterior si ya has enviado tus confirmaciones a un repositorio compartido.
Resumen
Como resumen,
git reset
es un comando potente que sirve para deshacer los cambios locales en el estado de un repositorio de Git.
git reset
actúa en "los tres árboles de Git". Estos árboles son el historial de confirmaciones (
HEAD
), el índice del entorno de ensayo y el directorio de trabajo. Hay tres opciones de líneas de comandos que se corresponden con los tres árboles. Las opciones
--soft, --mixed
y
--hard
se pueden pasar a
git reset
.
En este artículo, hemos utilizado unos cuantos comandos distintos de Git para ayudar a mostrar los procesos de restablecimiento. Amplía la información sobre esos comandos en las siguientes páginas individuales:
git status
,
git log
,
git add
,
git checkout
,
git reflog
y
git revert
. |
| Markdown | [Saltar al contenido](https://www.atlassian.com/es/git/tutorials/undoing-changes/git-reset#content)
- [Productos](https://www.atlassian.com/es/git/tutorials/undoing-changes/git-reset)
Destacadas
Desarrolladores
Gestores de productos
Profesionales de TI
Equipos empresariales
Equipos de liderazgo
[Ver todas las aplicaciones](https://www.atlassian.com/es/software)
- ## Aplicaciones funcionales
- [**Jira** Gestión flexible de proyectos](https://www.atlassian.com/es/software/jira)
- [**Confluence** Todo el conocimiento en el mismo sitio](https://www.atlassian.com/es/software/confluence)
- [**Jira Service Management** Presta servicio a alta velocidad](https://www.atlassian.com/es/software/jira/service-management)
## Colecciones de Atlassian
- [Potencia el trabajo en equipo optimizado JiraConfluenceLoom](https://www.atlassian.com/es/collections/teamwork)
- [Optimiza la estrategia y los resultados con confianza FocusTalentAlign](https://www.atlassian.com/es/collections/strategy)
- [Presta tus servicios a gran velocidad Jira Service ManagementCustomer Service ManagementAssets](https://www.atlassian.com/es/collections/service)
- [Lanza software de calidad rápidamente Rovo DevDXPipelinesBitbucketCompass](https://www.atlassian.com/es/collections/software)
Con tecnología de
[Rovo Aplicaciones con tecnología de IA, impulsadas por el conocimiento de tu equipo.](https://www.atlassian.com/es/software/rovo)
- [**Jira** Gestión flexible de proyectos](https://www.atlassian.com/es/software/jira)
- [**Bitbucket** Código fuente y CI/CD](https://www.atlassian.com/es/software/bitbucket)
- [**Rovo Dev** Agentic AI para desarrolladores](https://www.atlassian.com/es/software/rovo-dev)
- [**Pipelines** Automatización de CI/CD escalable](https://www.atlassian.com/es/software/bitbucket/features/pipelines)
- [**DX** Mide la productividad y el impacto de la IA](https://www.atlassian.com/es/collections/software)
- [**Compass** Catálogo de software para equipos](https://www.atlassian.com/es/software/compass)
- [Lanza software de calidad rápidamente Rovo DevDXPipelinesBitbucketCompass](https://www.atlassian.com/es/collections/software)
[Rovo Aplicaciones con tecnología de IA, impulsadas por el conocimiento de tu equipo.](https://www.atlassian.com/es/software/rovo)
- [**Jira Product Discovery** Registra y prioriza las ideas](https://www.atlassian.com/es/software/jira/product-discovery)
- [**Jira** Gestión flexible de proyectos](https://www.atlassian.com/es/software/jira)
- [**Confluence** Todo el conocimiento en el mismo sitio](https://www.atlassian.com/es/software/confluence)
- [Potencia el trabajo en equipo optimizado JiraConfluenceLoom](https://www.atlassian.com/es/collections/teamwork)
[Rovo Aplicaciones con tecnología de IA, impulsadas por el conocimiento de tu equipo.](https://www.atlassian.com/es/software/rovo)
- [**Jira Service Management** Presta servicio a alta velocidad](https://www.atlassian.com/es/software/jira/service-management)
- [**Guard** Seguridad en la nube mejorada](https://www.atlassian.com/es/software/guard)
[Rovo Aplicaciones con tecnología de IA, impulsadas por el conocimiento de tu equipo.](https://www.atlassian.com/es/software/rovo)
- [**Jira** Gestión flexible de proyectos](https://www.atlassian.com/es/software/jira)
- [**Confluence** Todo el conocimiento en el mismo sitio](https://www.atlassian.com/es/software/confluence)
- [**Trello** Captura y organiza tus tareas](https://trello.com/home)
- [**Loom** Actualizaciones de vídeo rápidas y asíncronas](https://www.atlassian.com/es/software/loom)
- [**Jira Service Management** Presta servicio a alta velocidad](https://www.atlassian.com/es/software/jira/service-management)
- [**Customer Service Management** Experiencias de cliente reinventadas](https://www.atlassian.com/es/software/customer-service-management)
- [Potencia el trabajo en equipo optimizado JiraConfluenceLoom](https://www.atlassian.com/es/collections/teamwork)
[Rovo Aplicaciones con tecnología de IA, impulsadas por el conocimiento de tu equipo.](https://www.atlassian.com/es/software/rovo)
- [**Focus** Planificación estratégica a escala empresarial](https://www.atlassian.com/es/software/focus)
- [**Talent** Conocimiento sobre la planificación de la plantilla](https://www.atlassian.com/es/software/talent)
- [**Align** Valor y planificación del trabajo en toda la empresa](https://www.atlassian.com/es/software/jira/align)
- [Optimiza la estrategia y los resultados con confianza FocusTalentAlign](https://www.atlassian.com/es/collections/strategy)
[Rovo Aplicaciones con tecnología de IA, impulsadas por el conocimiento de tu equipo.](https://www.atlassian.com/es/software/rovo)
- [Soluciones](https://www.atlassian.com/es/git/tutorials/undoing-changes/git-reset)
Soluciones
## Por caso práctico
- [Colaboración de Equipos](https://www.atlassian.com/es/collections/teamwork)
- [Estrategia y planificación](https://www.atlassian.com/es/collections/strategy)
- [Gestión de servicios](https://www.atlassian.com/es/collections/service)
- [Desarrollo de software](https://www.atlassian.com/es/collections/software)
## Por equipo
- [Software](https://www.atlassian.com/es/collections/software)
- [Marketing](https://www.atlassian.com/es/teams/marketing)
- [TI](https://www.atlassian.com/es/teams/it)
- [Producto](https://www.atlassian.com/es/software/jira/product-discovery%20)
## Por tamaño
- [Enterprise](https://www.atlassian.com/es/enterprise)
- [Pequeños negocios](https://www.atlassian.com/es/software/small-business)
- [Startup](https://www.atlassian.com/es/software/startups)
- [Organizaciones sin fines de lucro](https://www.atlassian.com/es/teams/nonprofits)
## Por sector
- [Comercio minorista](https://www.atlassian.com/es/industries/retail)
- [Telecomunicaciones](https://www.atlassian.com/es/industries/telecom)
- [Servicios profesionales](https://www.atlassian.com/es/industries/professional-services)
- [Gobierno](https://www.atlassian.com/es/government)
[Rovo Aplicaciones con tecnología de IA, impulsadas por el conocimiento de tu equipo.](https://www.atlassian.com/es/software/rovo)
- [¿Por qué Atlassian?](https://www.atlassian.com/es/git/tutorials/undoing-changes/git-reset)
- [Sistema de trabajo NewEl modelo de Atlassian sobre la colaboración de los equipos](https://www.atlassian.com/es/system-of-work)
- [MarketplaceConecta miles de aplicaciones a tus productos de Atlassian](https://marketplace.atlassian.com/)
- [ClientesCasos prácticos e historias centrados en el trabajo en equipo](https://www.atlassian.com/es/customers)
- [FedRAMPSoluciones que cumplen los requisitos del sector público](https://www.atlassian.com/es/trust/compliance/resources/fedramp)
- [ResistenciaInfraestructura de alto rendimiento y de nivel empresarial](https://www.atlassian.com/es/trust/resilience)
- [PlataformaNuestra plataforma segura, fiable y profundamente integrada](https://www.atlassian.com/es/platform)
- [Trust CenterGarantiza la seguridad, la conformidad y la disponibilidad de tus datos](https://www.atlassian.com/es/trust)
- [Recursos](https://www.atlassian.com/es/git/tutorials/undoing-changes/git-reset)
- [Atención al clienteHaz preguntas, informa de errores y danos tu opinión](https://support.atlassian.com/)
- [Buscar un partnerConsultoría, formación y soporte para la personalización de productos](https://partnerdirectory.atlassian.com/es)
- [Atlassian AscendRecursos y soporte para tu transformación](https://www.atlassian.com/es/migration)
- [CommunityAprende, conecta y crece con la Comunidad de Atlassian](https://community.atlassian.com/)
## Soporte
## Recursos
- [Enterprise](https://www.atlassian.com/es/enterprise)
- Más +
Obtener gratis
Iniciar sesión
Iniciar sesión
- Productos
- Destacadas
- Desarrolladores
- Gestores de productos
- Profesionales de TI
- Equipos empresariales
- Equipos de liderazgo
- Soluciones
- ¿Por qué Atlassian?
- Recursos
- [Enterprise](https://www.atlassian.com/es/enterprise)
[Iniciar sesión](https://id.atlassian.com/login?continue=https%3A%2F%2Fwww.atlassian.com%2Fgateway%2Fapi%2Fstart%2Fauthredirect)
- ## Aplicaciones funcionales
- [Jira Gestión flexible de proyectos](https://www.atlassian.com/es/software/jira)
- [Confluence Todo el conocimiento en el mismo sitio](https://www.atlassian.com/es/software/confluence)
- [Jira Service Management Presta servicio a alta velocidad](https://www.atlassian.com/es/software/jira/service-management)
## Colecciones de Atlassian
- [Potencia el trabajo en equipo optimizado JiraConfluenceLoom](https://www.atlassian.com/es/collections/teamwork)
- [Optimiza la estrategia y los resultados con confianza FocusTalentAlign](https://www.atlassian.com/es/collections/strategy)
- [Presta tus servicios a gran velocidad Jira Service ManagementCustomer Service ManagementAssets](https://www.atlassian.com/es/collections/service)
- [Lanza software de calidad rápidamente Rovo DevDXPipelinesBitbucketCompass](https://www.atlassian.com/es/collections/software)
Con tecnología de
[Rovo Aplicaciones con tecnología de IA, impulsadas por el conocimiento de tu equipo.](https://www.atlassian.com/es/software/rovo)
Desarrolladores
- [**Jira** Gestión flexible de proyectos](https://www.atlassian.com/es/software/jira)
- [**Bitbucket** Código fuente y CI/CD](https://www.atlassian.com/es/software/bitbucket)
- [**Rovo Dev** Agentic AI para desarrolladores](https://www.atlassian.com/es/software/rovo-dev)
- [**Pipelines** Automatización de CI/CD escalable](https://www.atlassian.com/es/software/bitbucket/features/pipelines)
- [**DX** Mide la productividad y el impacto de la IA](https://www.atlassian.com/es/collections/software)
- [**Compass** Catálogo de software para equipos](https://www.atlassian.com/es/software/compass)
- [Lanza software de calidad rápidamente Rovo DevDXPipelinesBitbucketCompass](https://www.atlassian.com/es/collections/software)
[Rovo Aplicaciones con tecnología de IA, impulsadas por el conocimiento de tu equipo.](https://www.atlassian.com/es/software/rovo)
Gestores de productos
- [**Jira Product Discovery** Registra y prioriza las ideas](https://www.atlassian.com/es/software/jira/product-discovery)
- [**Jira** Gestión flexible de proyectos](https://www.atlassian.com/es/software/jira)
- [**Confluence** Todo el conocimiento en el mismo sitio](https://www.atlassian.com/es/software/confluence)
- [Potencia el trabajo en equipo optimizado JiraConfluenceLoom](https://www.atlassian.com/es/collections/teamwork)
[Rovo Aplicaciones con tecnología de IA, impulsadas por el conocimiento de tu equipo.](https://www.atlassian.com/es/software/rovo)
Profesionales de TI
- [**Jira Service Management** Presta servicio a alta velocidad](https://www.atlassian.com/es/software/jira/service-management)
- [**Guard** Seguridad en la nube mejorada](https://www.atlassian.com/es/software/guard)
[Rovo Aplicaciones con tecnología de IA, impulsadas por el conocimiento de tu equipo.](https://www.atlassian.com/es/software/rovo)
Equipos empresariales
- [**Jira** Gestión flexible de proyectos](https://www.atlassian.com/es/software/jira)
- [**Confluence** Todo el conocimiento en el mismo sitio](https://www.atlassian.com/es/software/confluence)
- [**Trello** Captura y organiza tus tareas](https://trello.com/home)
- [**Loom** Actualizaciones de vídeo rápidas y asíncronas](https://www.atlassian.com/es/software/loom)
- [**Jira Service Management** Presta servicio a alta velocidad](https://www.atlassian.com/es/software/jira/service-management)
- [**Customer Service Management** Experiencias de cliente reinventadas](https://www.atlassian.com/es/software/customer-service-management)
- [Potencia el trabajo en equipo optimizado JiraConfluenceLoom](https://www.atlassian.com/es/collections/teamwork)
[Rovo Aplicaciones con tecnología de IA, impulsadas por el conocimiento de tu equipo.](https://www.atlassian.com/es/software/rovo)
Equipos de liderazgo
- [**Focus** Planificación estratégica a escala empresarial](https://www.atlassian.com/es/software/focus)
- [**Talent** Conocimiento sobre la planificación de la plantilla](https://www.atlassian.com/es/software/talent)
- [**Align** Valor y planificación del trabajo en toda la empresa](https://www.atlassian.com/es/software/jira/align)
- [Optimiza la estrategia y los resultados con confianza FocusTalentAlign](https://www.atlassian.com/es/collections/strategy)
[Rovo Aplicaciones con tecnología de IA, impulsadas por el conocimiento de tu equipo.](https://www.atlassian.com/es/software/rovo)
Soluciones
## Por caso práctico
- [Colaboración de Equipos](https://www.atlassian.com/es/collections/teamwork)
- [Estrategia y planificación](https://www.atlassian.com/es/collections/strategy)
- [Gestión de servicios](https://www.atlassian.com/es/collections/service)
- [Desarrollo de software](https://www.atlassian.com/es/collections/software)
## Por equipo
- [Software](https://www.atlassian.com/es/collections/software)
- [Marketing](https://www.atlassian.com/es/teams/marketing)
- [TI](https://www.atlassian.com/es/teams/it)
- [Producto](https://www.atlassian.com/es/software/jira/product-discovery%20)
## Por tamaño
- [Enterprise](https://www.atlassian.com/es/enterprise)
- [Pequeños negocios](https://www.atlassian.com/es/software/small-business)
- [Startup](https://www.atlassian.com/es/software/startups)
- [Organizaciones sin fines de lucro](https://www.atlassian.com/es/teams/nonprofits)
## Por sector
- [Comercio minorista](https://www.atlassian.com/es/industries/retail)
- [Telecomunicaciones](https://www.atlassian.com/es/industries/telecom)
- [Servicios profesionales](https://www.atlassian.com/es/industries/professional-services)
- [Gobierno](https://www.atlassian.com/es/government)
[Rovo Aplicaciones con tecnología de IA, impulsadas por el conocimiento de tu equipo.](https://www.atlassian.com/es/software/rovo)
¿Por qué Atlassian?
[Sistema de trabajo NewEl modelo de Atlassian sobre la colaboración de los equipos](https://www.atlassian.com/es/system-of-work)
[MarketplaceConecta miles de aplicaciones a tus productos de Atlassian](https://marketplace.atlassian.com/)
[ClientesCasos prácticos e historias centrados en el trabajo en equipo](https://www.atlassian.com/es/customers)
[FedRAMPSoluciones que cumplen los requisitos del sector público](https://www.atlassian.com/es/trust/compliance/resources/fedramp)
[ResistenciaInfraestructura de alto rendimiento y de nivel empresarial](https://www.atlassian.com/es/trust/resilience)
[PlataformaNuestra plataforma segura, fiable y profundamente integrada](https://www.atlassian.com/es/platform)
[Trust CenterGarantiza la seguridad, la conformidad y la disponibilidad de tus datos](https://www.atlassian.com/es/trust)
Recursos
[Atención al clienteHaz preguntas, informa de errores y danos tu opinión](https://support.atlassian.com/)
[Buscar un partnerConsultoría, formación y soporte para la personalización de productos](https://partnerdirectory.atlassian.com/es)
[Atlassian AscendRecursos y soporte para tu transformación](https://www.atlassian.com/es/migration)
[CommunityAprende, conecta y crece con la Comunidad de Atlassian](https://community.atlassian.com/)
Soporte
- [Dudas generales](https://www.atlassian.com/es/company/contact/general-inquiries)
- [Servicio técnico](https://support.atlassian.com/contact/)
- [Asesoramiento sobre productos](https://www.atlassian.com/es/company/contact/product-evaluator-advice)
- [Precios y facturación](https://www.atlassian.com/es/company/contact/purchasing-licensing)
- [Soporte por parte de partners](https://www.atlassian.com/es/partners)
- [Soporte para desarrolladores](https://developer.atlassian.com/)
- [Soporte Enterprise](https://www.atlassian.com/es/enterprise/services)
- [Compras y licencias](https://www.atlassian.com/es/licensing/purchase-licensing)
Recursos
- [Gestión de proyectos](https://www.atlassian.com/es/project-management)
- [Colaboración en proyectos](https://www.atlassian.com/es/work-management/project-collaboration)
- [Metodología ágil](https://www.atlassian.com/es/agile)
- [Manual de estrategias del equipo](https://www.atlassian.com/es/team-playbook)
- [Atlassian Learning](https://community.atlassian.com/learning)
- [Documentación del producto](https://confluence.atlassian.com/display/ALLDOC/Atlassian+Documentation)
- [Empieza ya](https://www.atlassian.com/es/get-started)
[Saltar al contenido](https://www.atlassian.com/es/git/tutorials/undoing-changes/git-reset#content)
- Productos
- Destacadas
- Desarrolladores
- Gestores de productos
- Profesionales de TI
- Equipos empresariales
- Equipos de liderazgo
- Soluciones
- ¿Por qué Atlassian?
- Recursos
- [Enterprise](https://www.atlassian.com/es/enterprise)
[Iniciar sesión](https://id.atlassian.com/login?continue=https%3A%2F%2Fwww.atlassian.com%2Fgateway%2Fapi%2Fstart%2Fauthredirect)
- ## Aplicaciones funcionales
- [Jira Gestión flexible de proyectos](https://www.atlassian.com/es/software/jira)
- [Confluence Todo el conocimiento en el mismo sitio](https://www.atlassian.com/es/software/confluence)
- [Jira Service Management Presta servicio a alta velocidad](https://www.atlassian.com/es/software/jira/service-management)
## Colecciones de Atlassian
- [Potencia el trabajo en equipo optimizado JiraConfluenceLoom](https://www.atlassian.com/es/collections/teamwork)
- [Optimiza la estrategia y los resultados con confianza FocusTalentAlign](https://www.atlassian.com/es/collections/strategy)
- [Presta tus servicios a gran velocidad Jira Service ManagementCustomer Service ManagementAssets](https://www.atlassian.com/es/collections/service)
- [Lanza software de calidad rápidamente Rovo DevDXPipelinesBitbucketCompass](https://www.atlassian.com/es/collections/software)
Con tecnología de
[Rovo Aplicaciones con tecnología de IA, impulsadas por el conocimiento de tu equipo.](https://www.atlassian.com/es/software/rovo)
Desarrolladores
- [**Jira** Gestión flexible de proyectos](https://www.atlassian.com/es/software/jira)
- [**Bitbucket** Código fuente y CI/CD](https://www.atlassian.com/es/software/bitbucket)
- [**Rovo Dev** Agentic AI para desarrolladores](https://www.atlassian.com/es/software/rovo-dev)
- [**Pipelines** Automatización de CI/CD escalable](https://www.atlassian.com/es/software/bitbucket/features/pipelines)
- [**DX** Mide la productividad y el impacto de la IA](https://www.atlassian.com/es/collections/software)
- [**Compass** Catálogo de software para equipos](https://www.atlassian.com/es/software/compass)
- [Lanza software de calidad rápidamente Rovo DevDXPipelinesBitbucketCompass](https://www.atlassian.com/es/collections/software)
[Rovo Aplicaciones con tecnología de IA, impulsadas por el conocimiento de tu equipo.](https://www.atlassian.com/es/software/rovo)
Gestores de productos
- [**Jira Product Discovery** Registra y prioriza las ideas](https://www.atlassian.com/es/software/jira/product-discovery)
- [**Jira** Gestión flexible de proyectos](https://www.atlassian.com/es/software/jira)
- [**Confluence** Todo el conocimiento en el mismo sitio](https://www.atlassian.com/es/software/confluence)
- [Potencia el trabajo en equipo optimizado JiraConfluenceLoom](https://www.atlassian.com/es/collections/teamwork)
[Rovo Aplicaciones con tecnología de IA, impulsadas por el conocimiento de tu equipo.](https://www.atlassian.com/es/software/rovo)
Profesionales de TI
- [**Jira Service Management** Presta servicio a alta velocidad](https://www.atlassian.com/es/software/jira/service-management)
- [**Guard** Seguridad en la nube mejorada](https://www.atlassian.com/es/software/guard)
[Rovo Aplicaciones con tecnología de IA, impulsadas por el conocimiento de tu equipo.](https://www.atlassian.com/es/software/rovo)
Equipos empresariales
- [**Jira** Gestión flexible de proyectos](https://www.atlassian.com/es/software/jira)
- [**Confluence** Todo el conocimiento en el mismo sitio](https://www.atlassian.com/es/software/confluence)
- [**Trello** Captura y organiza tus tareas](https://trello.com/home)
- [**Loom** Actualizaciones de vídeo rápidas y asíncronas](https://www.atlassian.com/es/software/loom)
- [**Jira Service Management** Presta servicio a alta velocidad](https://www.atlassian.com/es/software/jira/service-management)
- [**Customer Service Management** Experiencias de cliente reinventadas](https://www.atlassian.com/es/software/customer-service-management)
- [Potencia el trabajo en equipo optimizado JiraConfluenceLoom](https://www.atlassian.com/es/collections/teamwork)
[Rovo Aplicaciones con tecnología de IA, impulsadas por el conocimiento de tu equipo.](https://www.atlassian.com/es/software/rovo)
Equipos de liderazgo
- [**Focus** Planificación estratégica a escala empresarial](https://www.atlassian.com/es/software/focus)
- [**Talent** Conocimiento sobre la planificación de la plantilla](https://www.atlassian.com/es/software/talent)
- [**Align** Valor y planificación del trabajo en toda la empresa](https://www.atlassian.com/es/software/jira/align)
- [Optimiza la estrategia y los resultados con confianza FocusTalentAlign](https://www.atlassian.com/es/collections/strategy)
[Rovo Aplicaciones con tecnología de IA, impulsadas por el conocimiento de tu equipo.](https://www.atlassian.com/es/software/rovo)
Soluciones
## Por caso práctico
- [Colaboración de Equipos](https://www.atlassian.com/es/collections/teamwork)
- [Estrategia y planificación](https://www.atlassian.com/es/collections/strategy)
- [Gestión de servicios](https://www.atlassian.com/es/collections/service)
- [Desarrollo de software](https://www.atlassian.com/es/collections/software)
## Por equipo
- [Software](https://www.atlassian.com/es/collections/software)
- [Marketing](https://www.atlassian.com/es/teams/marketing)
- [TI](https://www.atlassian.com/es/teams/it)
- [Producto](https://www.atlassian.com/es/software/jira/product-discovery%20)
## Por tamaño
- [Enterprise](https://www.atlassian.com/es/enterprise)
- [Pequeños negocios](https://www.atlassian.com/es/software/small-business)
- [Startup](https://www.atlassian.com/es/software/startups)
- [Organizaciones sin fines de lucro](https://www.atlassian.com/es/teams/nonprofits)
## Por sector
- [Comercio minorista](https://www.atlassian.com/es/industries/retail)
- [Telecomunicaciones](https://www.atlassian.com/es/industries/telecom)
- [Servicios profesionales](https://www.atlassian.com/es/industries/professional-services)
- [Gobierno](https://www.atlassian.com/es/government)
[Rovo Aplicaciones con tecnología de IA, impulsadas por el conocimiento de tu equipo.](https://www.atlassian.com/es/software/rovo)
¿Por qué Atlassian?
[Sistema de trabajo NewEl modelo de Atlassian sobre la colaboración de los equipos](https://www.atlassian.com/es/system-of-work)
[MarketplaceConecta miles de aplicaciones a tus productos de Atlassian](https://marketplace.atlassian.com/)
[ClientesCasos prácticos e historias centrados en el trabajo en equipo](https://www.atlassian.com/es/customers)
[FedRAMPSoluciones que cumplen los requisitos del sector público](https://www.atlassian.com/es/trust/compliance/resources/fedramp)
[ResistenciaInfraestructura de alto rendimiento y de nivel empresarial](https://www.atlassian.com/es/trust/resilience)
[PlataformaNuestra plataforma segura, fiable y profundamente integrada](https://www.atlassian.com/es/platform)
[Trust CenterGarantiza la seguridad, la conformidad y la disponibilidad de tus datos](https://www.atlassian.com/es/trust)
Recursos
[Atención al clienteHaz preguntas, informa de errores y danos tu opinión](https://support.atlassian.com/)
[Buscar un partnerConsultoría, formación y soporte para la personalización de productos](https://partnerdirectory.atlassian.com/es)
[Atlassian AscendRecursos y soporte para tu transformación](https://www.atlassian.com/es/migration)
[CommunityAprende, conecta y crece con la Comunidad de Atlassian](https://community.atlassian.com/)
Soporte
- [Dudas generales](https://www.atlassian.com/es/company/contact/general-inquiries)
- [Servicio técnico](https://support.atlassian.com/contact/)
- [Asesoramiento sobre productos](https://www.atlassian.com/es/company/contact/product-evaluator-advice)
- [Precios y facturación](https://www.atlassian.com/es/company/contact/purchasing-licensing)
- [Soporte por parte de partners](https://www.atlassian.com/es/partners)
- [Soporte para desarrolladores](https://developer.atlassian.com/)
- [Soporte Enterprise](https://www.atlassian.com/es/enterprise/services)
- [Compras y licencias](https://www.atlassian.com/es/licensing/purchase-licensing)
Recursos
- [Gestión de proyectos](https://www.atlassian.com/es/project-management)
- [Colaboración en proyectos](https://www.atlassian.com/es/work-management/project-collaboration)
- [Metodología ágil](https://www.atlassian.com/es/agile)
- [Manual de estrategias del equipo](https://www.atlassian.com/es/team-playbook)
- [Atlassian Learning](https://community.atlassian.com/learning)
- [Documentación del producto](https://confluence.atlassian.com/display/ALLDOC/Atlassian+Documentation)
- [Empieza ya](https://www.atlassian.com/es/get-started)
Temas sobre Git
- Aprende Git
- [Comandos de Git](https://www.atlassian.com/es/git/glossary)
- [Aprende a usar Git con Bitbucket Cloud](https://www.atlassian.com/es/git/tutorials/learn-git-with-bitbucket-cloud)
- [Obtén información sobre la revisión del código en Bitbucket Cloud](https://www.atlassian.com/es/git/tutorials/learn-about-code-review-in-bitbucket-cloud)
- [Aprende sobre ramas con Bitbucket Cloud](https://www.atlassian.com/es/git/tutorials/learn-branching-with-bitbucket-cloud)
- [Aprende sobre cómo deshacer cambios con Bitbucket Cloud](https://www.atlassian.com/es/git/tutorials/learn-undoing-changes-with-bitbucket)
- Principiante
- [Qué es el control de versiones](https://www.atlassian.com/es/git/tutorials/what-is-version-control)
- [Gestión del código fuente](https://www.atlassian.com/es/git/tutorials/source-code-management)
- [Qué es Git](https://www.atlassian.com/es/git/tutorials/what-is-git)
- [Por qué utilizar Git en tu organización](https://www.atlassian.com/es/git/tutorials/why-git)
- [Instalar Git](https://www.atlassian.com/es/git/tutorials/install-git)
- [SSH de Git](https://www.atlassian.com/es/git/tutorials/git-ssh)
- [Archivo Git](https://www.atlassian.com/es/git/tutorials/export-git-archive)
- [GitOps](https://www.atlassian.com/es/git/tutorials/gitops)
- [Chuleta de Git](https://www.atlassian.com/es/git/tutorials/atlassian-git-cheatsheet)
- Inicio
- Configuración de un repositorio
- [Presentación](https://www.atlassian.com/es/git/tutorials/setting-up-a-repository)
- [git init](https://www.atlassian.com/es/git/tutorials/setting-up-a-repository/git-init)
- [git clone](https://www.atlassian.com/es/git/tutorials/setting-up-a-repository/git-clone)
- [git config](https://www.atlassian.com/es/git/tutorials/setting-up-a-repository/git-config)
- [Alias de Git](https://www.atlassian.com/es/git/tutorials/git-alias)
- Guardado de cambios (git add)
- [Presentación](https://www.atlassian.com/es/git/tutorials/saving-changes)
- [git commit](https://www.atlassian.com/es/git/tutorials/saving-changes/git-commit)
- [git diff](https://www.atlassian.com/es/git/tutorials/saving-changes/git-diff)
- [git stash](https://www.atlassian.com/es/git/tutorials/saving-changes/git-stash)
- [.gitignore](https://www.atlassian.com/es/git/tutorials/saving-changes/gitignore)
- Examen de un repositorio
- [Presentación](https://www.atlassian.com/es/git/tutorials/inspecting-a-repository)
- [git tag](https://www.atlassian.com/es/git/tutorials/inspecting-a-repository/git-tag)
- [git blame](https://www.atlassian.com/es/git/tutorials/inspecting-a-repository/git-blame)
- Deshacer cambios
- [Presentación](https://www.atlassian.com/es/git/tutorials/undoing-changes)
- [git clean](https://www.atlassian.com/es/git/tutorials/undoing-changes/git-clean)
- [git revert](https://www.atlassian.com/es/git/tutorials/undoing-changes/git-revert)
- [git reset](https://www.atlassian.com/es/git/tutorials/undoing-changes/git-reset)
- [git rm](https://www.atlassian.com/es/git/tutorials/undoing-changes/git-rm)
- Reescritura del historial
- [Presentación](https://www.atlassian.com/es/git/tutorials/rewriting-history)
- [git rebase](https://www.atlassian.com/es/git/tutorials/rewriting-history/git-rebase)
- [git reflog](https://www.atlassian.com/es/git/tutorials/rewriting-history/git-reflog)
- Flujos de trabajo colaborativos
- Sincronización (git remote)
- [Presentación](https://www.atlassian.com/es/git/tutorials/syncing)
- [git fetch](https://www.atlassian.com/es/git/tutorials/syncing/git-fetch)
- [git push](https://www.atlassian.com/es/git/tutorials/syncing/git-push)
- [git pull](https://www.atlassian.com/es/git/tutorials/syncing/git-pull)
- [Realizar una pull request](https://www.atlassian.com/es/git/tutorials/making-a-pull-request)
- Uso de ramas (git branch)
- [Presentación](https://www.atlassian.com/es/git/tutorials/using-branches)
- [git checkout](https://www.atlassian.com/es/git/tutorials/using-branches/git-checkout)
- [Git merge](https://www.atlassian.com/es/git/tutorials/using-branches/git-merge)
- [Fusiona los conflictos](https://www.atlassian.com/es/git/tutorials/using-branches/merge-conflicts)
- [Combinación de estrategias](https://www.atlassian.com/es/git/tutorials/using-branches/merge-strategy)
- Comparar flujos de trabajo
- [Presentación](https://www.atlassian.com/es/git/tutorials/comparing-workflows)
- [Flujo de trabajo de rama de función](https://www.atlassian.com/es/git/tutorials/comparing-workflows/feature-branch-workflow)
- [Flujo de trabajo de Gitflow](https://www.atlassian.com/es/git/tutorials/comparing-workflows/gitflow-workflow)
- [Flujo de trabajo de bifurcación](https://www.atlassian.com/es/git/tutorials/comparing-workflows/forking-workflow)
- Migración a Git
- [De SVN a Git: prepárate para la migración](https://www.atlassian.com/es/git/tutorials/svn-to-git-prepping-your-team-migration)
- Migración a Git desde SVN
- [Presentación](https://www.atlassian.com/es/git/tutorials/migrating-overview)
- [Preparar](https://www.atlassian.com/es/git/tutorials/migrating-prepare)
- [Convertir](https://www.atlassian.com/es/git/tutorials/migrating-convert)
- [Sincronizar](https://www.atlassian.com/es/git/tutorials/migrating-synchronize)
- [Compartir](https://www.atlassian.com/es/git/tutorials/migrating-share)
- [Migración](https://www.atlassian.com/es/git/tutorials/migrating-migrate)
- [De Perforce a Git: por qué dar el paso](https://www.atlassian.com/es/git/tutorials/perforce-git)
- [Migración de Perforce a Git](https://www.atlassian.com/es/git/tutorials/perforce-git-migration)
- [Trabajar con Git y Perforce: flujo de trabajo de integración](https://www.atlassian.com/es/git/tutorials/git-p4)
- [Cómo mover un repositorio de Git con historial](https://www.atlassian.com/es/git/tutorials/git-move-repository)
- Consejos avanzados
- [Presentación](https://www.atlassian.com/es/git/tutorials/advanced-overview)
- [La fusión frente a la reorganización](https://www.atlassian.com/es/git/tutorials/merging-vs-rebasing)
- [Restablecimiento, extracción y reversión](https://www.atlassian.com/es/git/tutorials/resetting-checking-out-and-reverting)
- [Git log avanzado](https://www.atlassian.com/es/git/tutorials/git-log)
- [Hooks de Git](https://www.atlassian.com/es/git/tutorials/git-hooks)
- [Referencias y registro de referencias](https://www.atlassian.com/es/git/tutorials/refs-and-the-reflog)
- [Submódulos de Git](https://www.atlassian.com/es/git/tutorials/git-submodule)
- [Subárbol de Git](https://www.atlassian.com/es/git/tutorials/git-subtree)
- [Grandes repositorios en Git](https://www.atlassian.com/es/git/tutorials/big-repositories)
- [Git LFS](https://www.atlassian.com/es/git/tutorials/git-lfs)
- [Git gc](https://www.atlassian.com/es/git/tutorials/git-gc)
- [Git prune](https://www.atlassian.com/es/git/tutorials/git-prune)
- [Git bash](https://www.atlassian.com/es/git/tutorials/git-bash)
- [Cómo almacenar archivos ocultos](https://www.atlassian.com/es/git/tutorials/dotfiles)
- [Git Cherry Pick](https://www.atlassian.com/es/git/tutorials/cherry-pick)
- [GitK](https://www.atlassian.com/es/git/tutorials/gitk)
- [Git-show](https://www.atlassian.com/es/git/tutorials/git-show)
- Artículos
- [Lidiar con las dependencias de Maven al cambiar a Git (en inglés)](https://www.atlassian.com/es/git/articles/maven-dependencies-versions-merging)
- [Dominio de las solicitudes de incorporación de cambios: ¡descubre las capacidades de recuperación! (en inglés)](https://www.atlassian.com/es/git/articles/pull-request-proficiency-fetching-abilities-unlocked)
- [Git y dependencias de proyectos](https://www.atlassian.com/es/git/articles/git-and-project-dependencies)
- [¿Git o SVN? Nuance Healthcare se decantó por un modelo de creación de ramas de Git](https://www.atlassian.com/es/git/articles/git-or-svn-git-branching-model)
- [Bifurcaciones y repositorios upstream: instrucciones y consejo interesante (en inglés)](https://www.atlassian.com/es/git/tutorials/git-forks-and-upstreams)
- [Conceptos básicos, flujos de trabajo y consejos](https://www.atlassian.com/es/git/articles/core-concept-workflows-and-tips)
Temas sobre Git
- Aprende Git
- [Comandos de Git](https://www.atlassian.com/es/git/glossary)
- [Aprende a usar Git con Bitbucket Cloud](https://www.atlassian.com/es/git/tutorials/learn-git-with-bitbucket-cloud)
- [Obtén información sobre la revisión del código en Bitbucket Cloud](https://www.atlassian.com/es/git/tutorials/learn-about-code-review-in-bitbucket-cloud)
- [Aprende sobre ramas con Bitbucket Cloud](https://www.atlassian.com/es/git/tutorials/learn-branching-with-bitbucket-cloud)
- [Aprende sobre cómo deshacer cambios con Bitbucket Cloud](https://www.atlassian.com/es/git/tutorials/learn-undoing-changes-with-bitbucket)
- Principiante
- [Qué es el control de versiones](https://www.atlassian.com/es/git/tutorials/what-is-version-control)
- [Gestión del código fuente](https://www.atlassian.com/es/git/tutorials/source-code-management)
- [Qué es Git](https://www.atlassian.com/es/git/tutorials/what-is-git)
- [Por qué utilizar Git en tu organización](https://www.atlassian.com/es/git/tutorials/why-git)
- [Instalar Git](https://www.atlassian.com/es/git/tutorials/install-git)
- [SSH de Git](https://www.atlassian.com/es/git/tutorials/git-ssh)
- [Archivo Git](https://www.atlassian.com/es/git/tutorials/export-git-archive)
- [GitOps](https://www.atlassian.com/es/git/tutorials/gitops)
- [Chuleta de Git](https://www.atlassian.com/es/git/tutorials/atlassian-git-cheatsheet)
- Inicio
- Configuración de un repositorio
- [Presentación](https://www.atlassian.com/es/git/tutorials/setting-up-a-repository)
- [git init](https://www.atlassian.com/es/git/tutorials/setting-up-a-repository/git-init)
- [git clone](https://www.atlassian.com/es/git/tutorials/setting-up-a-repository/git-clone)
- [git config](https://www.atlassian.com/es/git/tutorials/setting-up-a-repository/git-config)
- [Alias de Git](https://www.atlassian.com/es/git/tutorials/git-alias)
- Guardado de cambios (git add)
- [Presentación](https://www.atlassian.com/es/git/tutorials/saving-changes)
- [git commit](https://www.atlassian.com/es/git/tutorials/saving-changes/git-commit)
- [git diff](https://www.atlassian.com/es/git/tutorials/saving-changes/git-diff)
- [git stash](https://www.atlassian.com/es/git/tutorials/saving-changes/git-stash)
- [.gitignore](https://www.atlassian.com/es/git/tutorials/saving-changes/gitignore)
- Examen de un repositorio
- [Presentación](https://www.atlassian.com/es/git/tutorials/inspecting-a-repository)
- [git tag](https://www.atlassian.com/es/git/tutorials/inspecting-a-repository/git-tag)
- [git blame](https://www.atlassian.com/es/git/tutorials/inspecting-a-repository/git-blame)
- Deshacer cambios
- [Presentación](https://www.atlassian.com/es/git/tutorials/undoing-changes)
- [git clean](https://www.atlassian.com/es/git/tutorials/undoing-changes/git-clean)
- [git revert](https://www.atlassian.com/es/git/tutorials/undoing-changes/git-revert)
- [git reset](https://www.atlassian.com/es/git/tutorials/undoing-changes/git-reset)
- [git rm](https://www.atlassian.com/es/git/tutorials/undoing-changes/git-rm)
- Reescritura del historial
- [Presentación](https://www.atlassian.com/es/git/tutorials/rewriting-history)
- [git rebase](https://www.atlassian.com/es/git/tutorials/rewriting-history/git-rebase)
- [git reflog](https://www.atlassian.com/es/git/tutorials/rewriting-history/git-reflog)
- Flujos de trabajo colaborativos
- Sincronización (git remote)
- [Presentación](https://www.atlassian.com/es/git/tutorials/syncing)
- [git fetch](https://www.atlassian.com/es/git/tutorials/syncing/git-fetch)
- [git push](https://www.atlassian.com/es/git/tutorials/syncing/git-push)
- [git pull](https://www.atlassian.com/es/git/tutorials/syncing/git-pull)
- [Realizar una pull request](https://www.atlassian.com/es/git/tutorials/making-a-pull-request)
- Uso de ramas (git branch)
- [Presentación](https://www.atlassian.com/es/git/tutorials/using-branches)
- [git checkout](https://www.atlassian.com/es/git/tutorials/using-branches/git-checkout)
- [Git merge](https://www.atlassian.com/es/git/tutorials/using-branches/git-merge)
- [Fusiona los conflictos](https://www.atlassian.com/es/git/tutorials/using-branches/merge-conflicts)
- [Combinación de estrategias](https://www.atlassian.com/es/git/tutorials/using-branches/merge-strategy)
- Comparar flujos de trabajo
- [Presentación](https://www.atlassian.com/es/git/tutorials/comparing-workflows)
- [Flujo de trabajo de rama de función](https://www.atlassian.com/es/git/tutorials/comparing-workflows/feature-branch-workflow)
- [Flujo de trabajo de Gitflow](https://www.atlassian.com/es/git/tutorials/comparing-workflows/gitflow-workflow)
- [Flujo de trabajo de bifurcación](https://www.atlassian.com/es/git/tutorials/comparing-workflows/forking-workflow)
- Migración a Git
- [De SVN a Git: prepárate para la migración](https://www.atlassian.com/es/git/tutorials/svn-to-git-prepping-your-team-migration)
- Migración a Git desde SVN
- [Presentación](https://www.atlassian.com/es/git/tutorials/migrating-overview)
- [Preparar](https://www.atlassian.com/es/git/tutorials/migrating-prepare)
- [Convertir](https://www.atlassian.com/es/git/tutorials/migrating-convert)
- [Sincronizar](https://www.atlassian.com/es/git/tutorials/migrating-synchronize)
- [Compartir](https://www.atlassian.com/es/git/tutorials/migrating-share)
- [Migración](https://www.atlassian.com/es/git/tutorials/migrating-migrate)
- [De Perforce a Git: por qué dar el paso](https://www.atlassian.com/es/git/tutorials/perforce-git)
- [Migración de Perforce a Git](https://www.atlassian.com/es/git/tutorials/perforce-git-migration)
- [Trabajar con Git y Perforce: flujo de trabajo de integración](https://www.atlassian.com/es/git/tutorials/git-p4)
- [Cómo mover un repositorio de Git con historial](https://www.atlassian.com/es/git/tutorials/git-move-repository)
- Consejos avanzados
- [Presentación](https://www.atlassian.com/es/git/tutorials/advanced-overview)
- [La fusión frente a la reorganización](https://www.atlassian.com/es/git/tutorials/merging-vs-rebasing)
- [Restablecimiento, extracción y reversión](https://www.atlassian.com/es/git/tutorials/resetting-checking-out-and-reverting)
- [Git log avanzado](https://www.atlassian.com/es/git/tutorials/git-log)
- [Hooks de Git](https://www.atlassian.com/es/git/tutorials/git-hooks)
- [Referencias y registro de referencias](https://www.atlassian.com/es/git/tutorials/refs-and-the-reflog)
- [Submódulos de Git](https://www.atlassian.com/es/git/tutorials/git-submodule)
- [Subárbol de Git](https://www.atlassian.com/es/git/tutorials/git-subtree)
- [Grandes repositorios en Git](https://www.atlassian.com/es/git/tutorials/big-repositories)
- [Git LFS](https://www.atlassian.com/es/git/tutorials/git-lfs)
- [Git gc](https://www.atlassian.com/es/git/tutorials/git-gc)
- [Git prune](https://www.atlassian.com/es/git/tutorials/git-prune)
- [Git bash](https://www.atlassian.com/es/git/tutorials/git-bash)
- [Cómo almacenar archivos ocultos](https://www.atlassian.com/es/git/tutorials/dotfiles)
- [Git Cherry Pick](https://www.atlassian.com/es/git/tutorials/cherry-pick)
- [GitK](https://www.atlassian.com/es/git/tutorials/gitk)
- [Git-show](https://www.atlassian.com/es/git/tutorials/git-show)
- Artículos
- [Lidiar con las dependencias de Maven al cambiar a Git (en inglés)](https://www.atlassian.com/es/git/articles/maven-dependencies-versions-merging)
- [Dominio de las solicitudes de incorporación de cambios: ¡descubre las capacidades de recuperación! (en inglés)](https://www.atlassian.com/es/git/articles/pull-request-proficiency-fetching-abilities-unlocked)
- [Git y dependencias de proyectos](https://www.atlassian.com/es/git/articles/git-and-project-dependencies)
- [¿Git o SVN? Nuance Healthcare se decantó por un modelo de creación de ramas de Git](https://www.atlassian.com/es/git/articles/git-or-svn-git-branching-model)
- [Bifurcaciones y repositorios upstream: instrucciones y consejo interesante (en inglés)](https://www.atlassian.com/es/git/tutorials/git-forks-and-upstreams)
- [Conceptos básicos, flujos de trabajo y consejos](https://www.atlassian.com/es/git/articles/core-concept-workflows-and-tips)
Temas sobre Git
- Aprende Git
- [Comandos de Git](https://www.atlassian.com/es/git/glossary)
- [Aprende a usar Git con Bitbucket Cloud](https://www.atlassian.com/es/git/tutorials/learn-git-with-bitbucket-cloud)
- [Obtén información sobre la revisión del código en Bitbucket Cloud](https://www.atlassian.com/es/git/tutorials/learn-about-code-review-in-bitbucket-cloud)
- [Aprende sobre ramas con Bitbucket Cloud](https://www.atlassian.com/es/git/tutorials/learn-branching-with-bitbucket-cloud)
- [Aprende sobre cómo deshacer cambios con Bitbucket Cloud](https://www.atlassian.com/es/git/tutorials/learn-undoing-changes-with-bitbucket)
- Principiante
- [Qué es el control de versiones](https://www.atlassian.com/es/git/tutorials/what-is-version-control)
- [Gestión del código fuente](https://www.atlassian.com/es/git/tutorials/source-code-management)
- [Qué es Git](https://www.atlassian.com/es/git/tutorials/what-is-git)
- [Por qué utilizar Git en tu organización](https://www.atlassian.com/es/git/tutorials/why-git)
- [Instalar Git](https://www.atlassian.com/es/git/tutorials/install-git)
- [SSH de Git](https://www.atlassian.com/es/git/tutorials/git-ssh)
- [Archivo Git](https://www.atlassian.com/es/git/tutorials/export-git-archive)
- [GitOps](https://www.atlassian.com/es/git/tutorials/gitops)
- [Chuleta de Git](https://www.atlassian.com/es/git/tutorials/atlassian-git-cheatsheet)
- Inicio
- Configuración de un repositorio
- [Presentación](https://www.atlassian.com/es/git/tutorials/setting-up-a-repository)
- [git init](https://www.atlassian.com/es/git/tutorials/setting-up-a-repository/git-init)
- [git clone](https://www.atlassian.com/es/git/tutorials/setting-up-a-repository/git-clone)
- [git config](https://www.atlassian.com/es/git/tutorials/setting-up-a-repository/git-config)
- [Alias de Git](https://www.atlassian.com/es/git/tutorials/git-alias)
- Guardado de cambios (git add)
- [Presentación](https://www.atlassian.com/es/git/tutorials/saving-changes)
- [git commit](https://www.atlassian.com/es/git/tutorials/saving-changes/git-commit)
- [git diff](https://www.atlassian.com/es/git/tutorials/saving-changes/git-diff)
- [git stash](https://www.atlassian.com/es/git/tutorials/saving-changes/git-stash)
- [.gitignore](https://www.atlassian.com/es/git/tutorials/saving-changes/gitignore)
- Examen de un repositorio
- [Presentación](https://www.atlassian.com/es/git/tutorials/inspecting-a-repository)
- [git tag](https://www.atlassian.com/es/git/tutorials/inspecting-a-repository/git-tag)
- [git blame](https://www.atlassian.com/es/git/tutorials/inspecting-a-repository/git-blame)
- Deshacer cambios
- [Presentación](https://www.atlassian.com/es/git/tutorials/undoing-changes)
- [git clean](https://www.atlassian.com/es/git/tutorials/undoing-changes/git-clean)
- [git revert](https://www.atlassian.com/es/git/tutorials/undoing-changes/git-revert)
- [git reset](https://www.atlassian.com/es/git/tutorials/undoing-changes/git-reset)
- [git rm](https://www.atlassian.com/es/git/tutorials/undoing-changes/git-rm)
- Reescritura del historial
- [Presentación](https://www.atlassian.com/es/git/tutorials/rewriting-history)
- [git rebase](https://www.atlassian.com/es/git/tutorials/rewriting-history/git-rebase)
- [git reflog](https://www.atlassian.com/es/git/tutorials/rewriting-history/git-reflog)
- Flujos de trabajo colaborativos
- Sincronización (git remote)
- [Presentación](https://www.atlassian.com/es/git/tutorials/syncing)
- [git fetch](https://www.atlassian.com/es/git/tutorials/syncing/git-fetch)
- [git push](https://www.atlassian.com/es/git/tutorials/syncing/git-push)
- [git pull](https://www.atlassian.com/es/git/tutorials/syncing/git-pull)
- [Realizar una pull request](https://www.atlassian.com/es/git/tutorials/making-a-pull-request)
- Uso de ramas (git branch)
- [Presentación](https://www.atlassian.com/es/git/tutorials/using-branches)
- [git checkout](https://www.atlassian.com/es/git/tutorials/using-branches/git-checkout)
- [Git merge](https://www.atlassian.com/es/git/tutorials/using-branches/git-merge)
- [Fusiona los conflictos](https://www.atlassian.com/es/git/tutorials/using-branches/merge-conflicts)
- [Combinación de estrategias](https://www.atlassian.com/es/git/tutorials/using-branches/merge-strategy)
- Comparar flujos de trabajo
- [Presentación](https://www.atlassian.com/es/git/tutorials/comparing-workflows)
- [Flujo de trabajo de rama de función](https://www.atlassian.com/es/git/tutorials/comparing-workflows/feature-branch-workflow)
- [Flujo de trabajo de Gitflow](https://www.atlassian.com/es/git/tutorials/comparing-workflows/gitflow-workflow)
- [Flujo de trabajo de bifurcación](https://www.atlassian.com/es/git/tutorials/comparing-workflows/forking-workflow)
- Migración a Git
- [De SVN a Git: prepárate para la migración](https://www.atlassian.com/es/git/tutorials/svn-to-git-prepping-your-team-migration)
- Migración a Git desde SVN
- [Presentación](https://www.atlassian.com/es/git/tutorials/migrating-overview)
- [Preparar](https://www.atlassian.com/es/git/tutorials/migrating-prepare)
- [Convertir](https://www.atlassian.com/es/git/tutorials/migrating-convert)
- [Sincronizar](https://www.atlassian.com/es/git/tutorials/migrating-synchronize)
- [Compartir](https://www.atlassian.com/es/git/tutorials/migrating-share)
- [Migración](https://www.atlassian.com/es/git/tutorials/migrating-migrate)
- [De Perforce a Git: por qué dar el paso](https://www.atlassian.com/es/git/tutorials/perforce-git)
- [Migración de Perforce a Git](https://www.atlassian.com/es/git/tutorials/perforce-git-migration)
- [Trabajar con Git y Perforce: flujo de trabajo de integración](https://www.atlassian.com/es/git/tutorials/git-p4)
- [Cómo mover un repositorio de Git con historial](https://www.atlassian.com/es/git/tutorials/git-move-repository)
- Consejos avanzados
- [Presentación](https://www.atlassian.com/es/git/tutorials/advanced-overview)
- [La fusión frente a la reorganización](https://www.atlassian.com/es/git/tutorials/merging-vs-rebasing)
- [Restablecimiento, extracción y reversión](https://www.atlassian.com/es/git/tutorials/resetting-checking-out-and-reverting)
- [Git log avanzado](https://www.atlassian.com/es/git/tutorials/git-log)
- [Hooks de Git](https://www.atlassian.com/es/git/tutorials/git-hooks)
- [Referencias y registro de referencias](https://www.atlassian.com/es/git/tutorials/refs-and-the-reflog)
- [Submódulos de Git](https://www.atlassian.com/es/git/tutorials/git-submodule)
- [Subárbol de Git](https://www.atlassian.com/es/git/tutorials/git-subtree)
- [Grandes repositorios en Git](https://www.atlassian.com/es/git/tutorials/big-repositories)
- [Git LFS](https://www.atlassian.com/es/git/tutorials/git-lfs)
- [Git gc](https://www.atlassian.com/es/git/tutorials/git-gc)
- [Git prune](https://www.atlassian.com/es/git/tutorials/git-prune)
- [Git bash](https://www.atlassian.com/es/git/tutorials/git-bash)
- [Cómo almacenar archivos ocultos](https://www.atlassian.com/es/git/tutorials/dotfiles)
- [Git Cherry Pick](https://www.atlassian.com/es/git/tutorials/cherry-pick)
- [GitK](https://www.atlassian.com/es/git/tutorials/gitk)
- [Git-show](https://www.atlassian.com/es/git/tutorials/git-show)
- Artículos
- [Lidiar con las dependencias de Maven al cambiar a Git (en inglés)](https://www.atlassian.com/es/git/articles/maven-dependencies-versions-merging)
- [Dominio de las solicitudes de incorporación de cambios: ¡descubre las capacidades de recuperación! (en inglés)](https://www.atlassian.com/es/git/articles/pull-request-proficiency-fetching-abilities-unlocked)
- [Git y dependencias de proyectos](https://www.atlassian.com/es/git/articles/git-and-project-dependencies)
- [¿Git o SVN? Nuance Healthcare se decantó por un modelo de creación de ramas de Git](https://www.atlassian.com/es/git/articles/git-or-svn-git-branching-model)
- [Bifurcaciones y repositorios upstream: instrucciones y consejo interesante (en inglés)](https://www.atlassian.com/es/git/tutorials/git-forks-and-upstreams)
- [Conceptos básicos, flujos de trabajo y consejos](https://www.atlassian.com/es/git/articles/core-concept-workflows-and-tips)
Temas sobre Git
- Aprende Git
- [Comandos de Git](https://www.atlassian.com/es/git/glossary)
- [Aprende a usar Git con Bitbucket Cloud](https://www.atlassian.com/es/git/tutorials/learn-git-with-bitbucket-cloud)
- [Obtén información sobre la revisión del código en Bitbucket Cloud](https://www.atlassian.com/es/git/tutorials/learn-about-code-review-in-bitbucket-cloud)
- [Aprende sobre ramas con Bitbucket Cloud](https://www.atlassian.com/es/git/tutorials/learn-branching-with-bitbucket-cloud)
- [Aprende sobre cómo deshacer cambios con Bitbucket Cloud](https://www.atlassian.com/es/git/tutorials/learn-undoing-changes-with-bitbucket)
- Principiante
- [Qué es el control de versiones](https://www.atlassian.com/es/git/tutorials/what-is-version-control)
- [Gestión del código fuente](https://www.atlassian.com/es/git/tutorials/source-code-management)
- [Qué es Git](https://www.atlassian.com/es/git/tutorials/what-is-git)
- [Por qué utilizar Git en tu organización](https://www.atlassian.com/es/git/tutorials/why-git)
- [Instalar Git](https://www.atlassian.com/es/git/tutorials/install-git)
- [SSH de Git](https://www.atlassian.com/es/git/tutorials/git-ssh)
- [Archivo Git](https://www.atlassian.com/es/git/tutorials/export-git-archive)
- [GitOps](https://www.atlassian.com/es/git/tutorials/gitops)
- [Chuleta de Git](https://www.atlassian.com/es/git/tutorials/atlassian-git-cheatsheet)
- Inicio
- Configuración de un repositorio
- [Presentación](https://www.atlassian.com/es/git/tutorials/setting-up-a-repository)
- [git init](https://www.atlassian.com/es/git/tutorials/setting-up-a-repository/git-init)
- [git clone](https://www.atlassian.com/es/git/tutorials/setting-up-a-repository/git-clone)
- [git config](https://www.atlassian.com/es/git/tutorials/setting-up-a-repository/git-config)
- [Alias de Git](https://www.atlassian.com/es/git/tutorials/git-alias)
- Guardado de cambios (git add)
- [Presentación](https://www.atlassian.com/es/git/tutorials/saving-changes)
- [git commit](https://www.atlassian.com/es/git/tutorials/saving-changes/git-commit)
- [git diff](https://www.atlassian.com/es/git/tutorials/saving-changes/git-diff)
- [git stash](https://www.atlassian.com/es/git/tutorials/saving-changes/git-stash)
- [.gitignore](https://www.atlassian.com/es/git/tutorials/saving-changes/gitignore)
- Examen de un repositorio
- [Presentación](https://www.atlassian.com/es/git/tutorials/inspecting-a-repository)
- [git tag](https://www.atlassian.com/es/git/tutorials/inspecting-a-repository/git-tag)
- [git blame](https://www.atlassian.com/es/git/tutorials/inspecting-a-repository/git-blame)
- Deshacer cambios
- [Presentación](https://www.atlassian.com/es/git/tutorials/undoing-changes)
- [git clean](https://www.atlassian.com/es/git/tutorials/undoing-changes/git-clean)
- [git revert](https://www.atlassian.com/es/git/tutorials/undoing-changes/git-revert)
- [git reset](https://www.atlassian.com/es/git/tutorials/undoing-changes/git-reset)
- [git rm](https://www.atlassian.com/es/git/tutorials/undoing-changes/git-rm)
- Reescritura del historial
- [Presentación](https://www.atlassian.com/es/git/tutorials/rewriting-history)
- [git rebase](https://www.atlassian.com/es/git/tutorials/rewriting-history/git-rebase)
- [git reflog](https://www.atlassian.com/es/git/tutorials/rewriting-history/git-reflog)
- Flujos de trabajo colaborativos
- Sincronización (git remote)
- [Presentación](https://www.atlassian.com/es/git/tutorials/syncing)
- [git fetch](https://www.atlassian.com/es/git/tutorials/syncing/git-fetch)
- [git push](https://www.atlassian.com/es/git/tutorials/syncing/git-push)
- [git pull](https://www.atlassian.com/es/git/tutorials/syncing/git-pull)
- [Realizar una pull request](https://www.atlassian.com/es/git/tutorials/making-a-pull-request)
- Uso de ramas (git branch)
- [Presentación](https://www.atlassian.com/es/git/tutorials/using-branches)
- [git checkout](https://www.atlassian.com/es/git/tutorials/using-branches/git-checkout)
- [Git merge](https://www.atlassian.com/es/git/tutorials/using-branches/git-merge)
- [Fusiona los conflictos](https://www.atlassian.com/es/git/tutorials/using-branches/merge-conflicts)
- [Combinación de estrategias](https://www.atlassian.com/es/git/tutorials/using-branches/merge-strategy)
- Comparar flujos de trabajo
- [Presentación](https://www.atlassian.com/es/git/tutorials/comparing-workflows)
- [Flujo de trabajo de rama de función](https://www.atlassian.com/es/git/tutorials/comparing-workflows/feature-branch-workflow)
- [Flujo de trabajo de Gitflow](https://www.atlassian.com/es/git/tutorials/comparing-workflows/gitflow-workflow)
- [Flujo de trabajo de bifurcación](https://www.atlassian.com/es/git/tutorials/comparing-workflows/forking-workflow)
- Migración a Git
- [De SVN a Git: prepárate para la migración](https://www.atlassian.com/es/git/tutorials/svn-to-git-prepping-your-team-migration)
- Migración a Git desde SVN
- [Presentación](https://www.atlassian.com/es/git/tutorials/migrating-overview)
- [Preparar](https://www.atlassian.com/es/git/tutorials/migrating-prepare)
- [Convertir](https://www.atlassian.com/es/git/tutorials/migrating-convert)
- [Sincronizar](https://www.atlassian.com/es/git/tutorials/migrating-synchronize)
- [Compartir](https://www.atlassian.com/es/git/tutorials/migrating-share)
- [Migración](https://www.atlassian.com/es/git/tutorials/migrating-migrate)
- [De Perforce a Git: por qué dar el paso](https://www.atlassian.com/es/git/tutorials/perforce-git)
- [Migración de Perforce a Git](https://www.atlassian.com/es/git/tutorials/perforce-git-migration)
- [Trabajar con Git y Perforce: flujo de trabajo de integración](https://www.atlassian.com/es/git/tutorials/git-p4)
- [Cómo mover un repositorio de Git con historial](https://www.atlassian.com/es/git/tutorials/git-move-repository)
- Consejos avanzados
- [Presentación](https://www.atlassian.com/es/git/tutorials/advanced-overview)
- [La fusión frente a la reorganización](https://www.atlassian.com/es/git/tutorials/merging-vs-rebasing)
- [Restablecimiento, extracción y reversión](https://www.atlassian.com/es/git/tutorials/resetting-checking-out-and-reverting)
- [Git log avanzado](https://www.atlassian.com/es/git/tutorials/git-log)
- [Hooks de Git](https://www.atlassian.com/es/git/tutorials/git-hooks)
- [Referencias y registro de referencias](https://www.atlassian.com/es/git/tutorials/refs-and-the-reflog)
- [Submódulos de Git](https://www.atlassian.com/es/git/tutorials/git-submodule)
- [Subárbol de Git](https://www.atlassian.com/es/git/tutorials/git-subtree)
- [Grandes repositorios en Git](https://www.atlassian.com/es/git/tutorials/big-repositories)
- [Git LFS](https://www.atlassian.com/es/git/tutorials/git-lfs)
- [Git gc](https://www.atlassian.com/es/git/tutorials/git-gc)
- [Git prune](https://www.atlassian.com/es/git/tutorials/git-prune)
- [Git bash](https://www.atlassian.com/es/git/tutorials/git-bash)
- [Cómo almacenar archivos ocultos](https://www.atlassian.com/es/git/tutorials/dotfiles)
- [Git Cherry Pick](https://www.atlassian.com/es/git/tutorials/cherry-pick)
- [GitK](https://www.atlassian.com/es/git/tutorials/gitk)
- [Git-show](https://www.atlassian.com/es/git/tutorials/git-show)
- Artículos
- [Lidiar con las dependencias de Maven al cambiar a Git (en inglés)](https://www.atlassian.com/es/git/articles/maven-dependencies-versions-merging)
- [Dominio de las solicitudes de incorporación de cambios: ¡descubre las capacidades de recuperación! (en inglés)](https://www.atlassian.com/es/git/articles/pull-request-proficiency-fetching-abilities-unlocked)
- [Git y dependencias de proyectos](https://www.atlassian.com/es/git/articles/git-and-project-dependencies)
- [¿Git o SVN? Nuance Healthcare se decantó por un modelo de creación de ramas de Git](https://www.atlassian.com/es/git/articles/git-or-svn-git-branching-model)
- [Bifurcaciones y repositorios upstream: instrucciones y consejo interesante (en inglés)](https://www.atlassian.com/es/git/tutorials/git-forks-and-upstreams)
- [Conceptos básicos, flujos de trabajo y consejos](https://www.atlassian.com/es/git/articles/core-concept-workflows-and-tips)
# git reset
El comando `git reset` es una herramienta compleja y versátil para deshacer cambios. Se invoca principalmente de tres formas distintas, que se corresponden con los argumentos de líneas de comandos `--soft, --mixed y --hard`. Cada uno de los tres argumentos se corresponde con los tres mecanismos de gestión de estados internos de Git: el árbol de confirmaciones (`HEAD`), el índice del entorno de ensayo y el directorio de trabajo.
## Git reset y los tres árboles de Git
Para entender correctamente cómo utilizar `git reset`, primero tenemos que entender los sistemas de gestión de estados internos de Git. A veces, a estos mecanismos se les llama los "tres árboles" de Git. Puede que este nombre sea poco apropiado, ya que no son estrictamente estructuras de datos tradicionales en forma de árbol. Sin embargo, son estructuras de datos de nodos y basadas en punteros que Git utiliza para monitorizar un cronograma de ediciones. La mejor manera de demostrar estos mecanismos es crear un conjunto de cambios en un repositorio y seguirlo a lo largo de los tres árboles.
Para empezar, crearemos un nuevo repositorio con los siguientes comandos:
```
1$ mkdir git_reset_test
2$ cd git_reset_test/
3$ git init .
4Initialized empty Git repository in /git_reset_test/.git/
5$ touch reset_lifecycle_file
6$ git add reset_lifecycle_file
7$ git commit -m"initial commit"
8[main (root-commit) d386d86] initial commit
91 file changed, 0 insertions(+), 0 deletions(-)
10create mode 100644 reset_lifecycle_file
```
El código de ejemplo anterior crea un nuevo repositorio de Git con un único archivo vacío: `reset_lifecycle_file`. En este punto, el repositorio de ejemplo tiene una única confirmación (`d386d86`) de añadir `reset_lifecycle_file`.
## El directorio de trabajo
El primer árbol que examinaremos es "el directorio de trabajo". Este árbol está sincronizado con el sistema de archivos local y representa los cambios inmediatos que se realizan en el contenido de los archivos y los directorios.
```
1$ echo 'hello git reset' > reset_lifecycle_file
2 $ git status
3 On branch main
4 Changes not staged for commit:
5 (use "git add ..." to update what will be committed)
6 (use "git checkout -- ..." to discard changes in working directory)
7 modified: reset_lifecycle_file
```
En nuestro repositorio de ejemplo, modificamos y añadimos contenido a `reset_lifecycle_file`. Al invocar `git status`, se muestra que Git está al corriente de los cambios en el archivo. En ese momento estos cambios forman parte del primer árbol: "el directorio de trabajo". `git status` puede utilizarse para mostrar los cambios en el directorio de trabajo. Se mostrarán en rojo con el prefijo "modified".
## Índice del entorno de ensayo
El siguiente es el árbol del "índice del entorno de ensayo". Este árbol monitoriza los cambios en el directorio de trabajo, que se han aplicado con `git add`, para que se almacenen en la siguiente confirmación. Este árbol es un complejo mecanismo de almacenamiento en caché interno. Por lo general, Git intenta ocultar al usuario los pormenores de la implementación del índice del entorno de ensayo.
Para ver con exactitud el estado del índice del entorno de ensayo, debemos utilizar un comando de Git menos conocido: `git ls-files`. El comando `git ls-files` es, básicamente, una utilidad de depuración que sirve para inspeccionar el estado del árbol del índice del entorno de ensayo.
```
1git ls-files -s
2100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 0 reset_lifecycle_file
```
Aquí hemos ejecutado `git ls-files` con la opción `-s` o `--stage`. Sin la opción `-s`, el resultado de `git ls-files` es simplemente una lista de nombres de archivos y rutas que forman parte del índice en ese momento. La opción `-s` muestra metadatos adicionales de los archivos del índice del entorno de ensayo. Estos metadatos son los bits de modo, el nombre de objeto y el número de entorno del contenido preparado. A nosotros nos interesa el nombre de objeto, el segundo valor (`d7d77c1b04b5edd5acfc85de0b592449e5303770`). Se trata de un hash SHA-1 de objeto de Git estándar. Es un hash del contenido de los archivos. El historial de confirmaciones almacena sus propios SHA de objeto para identificar los punteros de confirmaciones y de referencias, y el índice del entorno de ensayo tiene sus propios SHA de objeto para monitorizar versiones de archivos en el índice.
A continuación, pasaremos el archivo `reset_lifecycle_file` modificado al índice del entorno de ensayo.
```
1$ git add reset_lifecycle_file
2
3
4$ git status
5
6
7On branch main Changes to be committed:
8
9
10(use "git reset HEAD ..." to unstage)
11
12
13modified: reset_lifecycle_file
```
Aquí hemos invocado `git add reset_lifecycle_file` que añade el archivo al índice del entorno de ensayo. Al invocar `git status`, ahora aparece `reset_lifecycle_file` en verde debajo de "Changes to be committed". Conviene resaltar que `git status` no es una representación verdadera del índice del entorno de ensayo. El resultado del comando `git status` muestra los cambios entre el historial de confirmaciones y el índice del entorno de ensayo. Llegados a este punto, vamos a examinar el contenido del índice del entorno de ensayo.
```
1$ git ls-files -s 100644 d7d77c1b04b5edd5acfc85de0b592449e5303770 0 reset_lifecycle_file
```
Podemos ver que el SHA de objeto de `reset_lifecycle_file` se ha actualizado de `e69de29bb2d1d6434b8b29ae775ad8c2e48c5391` a `d7d77c1b04b5edd5acfc85de0b592449e5303770`.
## Historial de confirmaciones
El último árbol es el historial de confirmaciones. El comando `git commit` añade cambios a una instantánea permanente que reside en el historial de confirmaciones. Esta instantánea también incluye el estado que tenía el índice del entorno de ensayo en el momento de efectuar la confirmación.
```
1$ git commit -am"update content of reset_lifecycle_file"
2[main dc67808] update content of reset_lifecycle_file
31 file changed, 1 insertion(+)
4$ git status
5On branch main
6nothing to commit, working tree clean
```
Aquí hemos creado una nueva confirmación con el mensaje `"update content of resetlifecyclefile"`. El conjunto de cambios se ha añadido al historial de confirmaciones. Al invocar `git status` en este momento, se muestra que no hay cambios pendientes en ninguno de los árboles. Al ejecutar `git log` se mostrará el historial de confirmaciones. Ahora que hemos seguido la trayectoria de este conjunto de cambios por los tres árboles, podemos empezar a utilizar `git reset`.
## Funcionamiento
A nivel superficial, `git reset` tiene un comportamiento parecido a `git checkout`. Mientras que `git checkout` solo opera en el puntero de referencia `HEAD`, `git reset` moverá el puntero de referencia `HEAD` y el puntero de referencia de la rama actual. Para demostrar mejor este comportamiento, vamos a analizar el siguiente ejemplo:

En este ejemplo se muestra una secuencia de confirmaciones en la rama `main`. La referencia `HEAD` y la referencia de la rama `main` en estos momentos apuntan a la confirmación d. Ahora vamos a ejecutar y a comparar tanto `git checkout b` como `git reset b`.
### git checkout b

Con `git checkout`, la referencia `main` sigue apuntando a `d`. La referencia `HEAD` se ha movido y ahora apunta a la confirmación `b`. Ahora el repositorio se encuentra en un estado de "`HEAD` desasociado".
### git reset b

En comparación, `git reset` mueve tanto las referencias de `HEAD` como las de la rama a la confirmación especificada.
Además de actualizar los punteros de referencia de las confirmaciones, `git reset` modificará el estado de los tres árboles. La modificación del puntero de referencia sucede siempre y es una actualización del tercer árbol, el árbol de confirmaciones. Los argumentos de las líneas de comandos `--soft, --mixed` y `--hard` indican cómo modificar los árboles del índice del entorno de ensayo y del directorio de trabajo.
## Opciones principales
La invocación predeterminada de `git reset` tiene argumentos implícitos de `--mixed` y `HEAD`. Esto significa que ejecutar `git reset` equivale a ejecutar `git reset --mixed HEAD`. De esta forma, `HEAD` es la confirmación especificada. En vez de `HEAD`, se puede usar cualquier hash de confirmación SHA-1 de Git.

## '--hard
Esta es la opción más directa, PELIGROSA y habitual. Cuando se pasa `--hard`, los punteros de referencia del historial de confirmaciones se actualizan a la confirmación especificada. A continuación, el índice del entorno de ensayo y el directorio de trabajo se restablecen para reflejar la confirmación especificada. Todos los cambios pendientes anteriores del índice del entorno de ensayo y del directorio de trabajo se restablecen para reflejar el estado del árbol de confirmaciones. Esto significa que se perderá cualquier trabajo pendiente que haya quedado en el índice del entorno de ensayo y en el directorio de trabajo.
Para demostrarlo, continuemos con el repositorio de ejemplo de los tres árboles que hemos visto antes. En primer lugar, hagamos unas cuantas modificaciones en el repositorio. Ejecuta los siguientes comandos en el repositorio de ejemplo:
```
1$ echo 'new file content' > new_file
2$ git add new_file
3$ echo 'changed content' >> reset_lifecycle_file
```
Estos comandos han creado un nuevo archivo llamado `new_file` y lo han añadido al repositorio. Además, se modificará el contenido de `reset_lifecycle_file`. Ahora que se han aplicado estos cambios, examinemos el estado del repositorio usando `git status`.
```
1$ git status
2On branch main
3Changes to be committed:
4 (use "git reset HEAD ..." to unstage)
5
6new file: new_file
7
8Changes not staged for commit:
9 (use "git add ..." to update what will be committed)
10 (use "git checkout -- ..." to discard changes in working directory)
11
12modified: reset_lifecycle_file
```
Aquí hemos invocado `git add reset_lifecycle_file` que añade el archivo al índice del entorno de ensayo. Al invocar `git status`, ahora aparece `reset_lifecycle_file` en verde debajo de "Changes to be committed". Conviene resaltar que `git status` no es una representación verdadera del índice del entorno de ensayo. El resultado del comando `git status` muestra los cambios entre el historial de confirmaciones y el índice del entorno de ensayo. Llegados a este punto, vamos a examinar el contenido del índice del entorno de ensayo.
```
1$ git ls-files -s
2100644 8e66654a5477b1bf4765946147c49509a431f963 0 new_file
3100644 d7d77c1b04b5edd5acfc85de0b592449e5303770 0 reset_lifecycle_file
```
Podemos ver que `new_file` se ha añadido al índice. Hemos efectuado modificaciones en `reset_lifecycle_file`, pero el SHA del índice del entorno de ensayo (`d7d77c1b04b5edd5acfc85de0b592449e5303770`) sigue siendo el mismo. Este es un comportamiento previsto, ya que no se ha usado `git add` para aplicar estos cambios en el índice del entorno de ensayo. Estos cambios existen en el directorio de trabajo.
Ahora vamos a ejecutar un comando `git reset --hard` y a examinar el nuevo estado del repositorio.
```
1$ git reset --hard
2HEAD is now at dc67808 update content of reset_lifecycle_file
3$ git status
4On branch main
5nothing to commit, working tree clean
6$ git ls-files -s
7100644 d7d77c1b04b5edd5acfc85de0b592449e5303770 0 reset_lifecycle_file
```
Aquí hemos ejecutado un "hard reset" utilizando la opción `--hard`. Git muestra el resultado indicando que `HEAD` apunta a la última confirmación `dc67808`. A continuación, comprobamos el estado del repositorio con `git status`. Git indica que no hay cambios pendientes. Examinamos también el estado del índice del entorno de ensayo y vemos que se ha restablecido a un punto anterior a que se añadiera `new_file`. Nuestras modificaciones en `reset_lifecycle_file` y la adición de `new_file` se han destruido. Esta pérdida de datos no se puede deshacer. Es esencial que tomemos buena nota de ello.
## '--mixed
Este es el modo de funcionamiento predeterminado. Se actualizan los punteros de referencia. El índice del entorno de ensayo se restablece al estado de la confirmación especificada. Todos los cambios que se hayan deshecho en el índice del entorno de ensayo se mueven al directorio de trabajo. Vamos a continuar.
```
1$ echo 'new file content' > new_file
2$ git add new_file
3$ echo 'append content' >> reset_lifecycle_file
4$ git add reset_lifecycle_file
5$ git status
6On branch main
7Changes to be committed:
8 (use "git reset HEAD ..." to unstage)
9
10new file: new_file
11modified: reset_lifecycle_file
12
13$ git ls-files -s
14100644 8e66654a5477b1bf4765946147c49509a431f963 0 new_file
15100644 7ab362db063f9e9426901092c00a3394b4bec53d 0 reset_lifecycle_file
```
En el ejemplo anterior, hemos hecho unas cuantas modificaciones en el repositorio. De nuevo, hemos añadido un `new_file` y modificado el contenido de `reset_lifecycle_file`. A continuación, estos cambios se aplican al índice del entorno de ensayo con `git add`. Con el repositorio en este estado, ejecutaremos ahora el restablecimiento.
```
1$ git reset --mixed
2$ git status
3On branch main
4Changes not staged for commit:
5 (use "git add ..." to update what will be committed)
6 (use "git checkout -- ..." to discard changes in working directory)
7
8modified: reset_lifecycle_file
9
10Untracked files:
11 (use "git add ..." to include in what will be committed)
12
13new_file
14
15no changes added to commit (use "git add" and/or "git commit -a")
16$ git ls-files -s
17100644 d7d77c1b04b5edd5acfc85de0b592449e5303770 0 reset_lifecycle_file
```
Aquí hemos ejecutado un "mixed reset". Para que quede claro, `--mixed` es el modo predeterminado y surte el mismo efecto que ejecutar `git reset`. Al examinar el resultado de `git status` y `git ls-files`, se ve que el índice del entorno de ensayo se ha restablecido a un estado en el que `reset_lifecycle_file` es el único archivo del índice. El SHA de objeto de `reset_lifecycle_file` se ha restablecido a la versión anterior.
Lo importante que debemos destacar aquí es que `git status` nos muestra que hay modificaciones en `reset_lifecycle_file` y que hay un archivo sin seguimiento: `new_file`. Este es el comportamiento `--mixed` explícito. Se ha restablecido el índice del entorno de ensayo y se han movido los cambios pendientes al directorio de trabajo. Solo tienes que compararlo con el caso del `--hard` reset, en el que se restablecieron tanto el índice del entorno de ensayo como el directorio de trabajo, lo que hizo que se perdieran estas actualizaciones.
## '--soft
Cuando se pasa el argumento `--soft`, se actualizan los punteros de referencia y el restablecimiento se detiene ahí. El índice del entorno de ensayo y el directorio de trabajo permanecen intactos. Puede ser difícil demostrar claramente este comportamiento. Vamos a continuar con nuestro repositorio demo y a prepararlo para un soft reset.
```
1$ git add reset_lifecycle_file
2
3
4$ git ls-files -s
5
6
7100644 67cc52710639e5da6b515416fd779d0741e3762e 0 reset_lifecycle_file
8
9
10$ git status
11
12
13On branch main
14
15
16Changes to be committed:
17
18
19(use "git reset HEAD ..." to unstage)
20
21
22modified: reset_lifecycle_file
23
24
25Untracked files:
26
27
28(use "git add ..." to include in what will be committed)
29
30
31new_file
```
Aquí hemos utilizado otra vez `git add` para pasar el `reset_lifecycle_file` modificado al índice del entorno de ensayo. Confirmamos que el índice se ha actualizado con el resultado de `git ls-files`. El resultado de `git status` ahora muestra "Changes to be committed" en verde. El `new_file` de nuestros ejemplos anteriores está flotando por el directorio de trabajo como un archivo sin seguimiento. Vamos a ejecutar rápidamente `rm new_file` para eliminar el archivo, puesto que no lo necesitaremos para los siguientes ejemplos.
Con el repositorio en este estado, ejecutaremos ahora un restablecimiento parcial (soft reset).
```
1$ git reset --soft
2$ git status
3On branch main
4Changes to be committed:
5 (use "git reset HEAD ..." to unstage)
6
7modified: reset_lifecycle_file
8$ git ls-files -s
9100644 67cc52710639e5da6b515416fd779d0741e3762e 0 reset_lifecycle_file
```
Hemos ejecutado un "soft reset". Al examinar el estado del repositorio con `git status` y `git ls-files`, se muestra que no ha cambiado nada. Es un comportamiento esperado. Un soft reset solo restablecerá el historial de confirmaciones. De manera predeterminada, `git reset` se invoca con `HEAD` como la confirmación objetivo. Como nuestro historial de confirmaciones ya se encontraba en `HEAD` y restablecemos implícitamente a `HEAD`, no ha ocurrido nada en realidad.
Para entender y utilizar mejor `--soft`, necesitamos una confirmación objetivo que no sea `HEAD`. Tenemos a `reset_lifecycle_file` en espera en el índice del entorno de ensayo. Vamos a crear una nueva confirmación.
```
1$ git commit -m"prepend content to reset_lifecycle_file"
```
En este punto, nuestro repositorio debería tener tres confirmaciones. Retrocederemos en el tiempo hasta la primera de ellas. Para ello, necesitaremos el ID de la primera confirmación. Se puede saber viendo el resultado desde `git log`.
```
1$ git log
2commit 62e793f6941c7e0d4ad9a1345a175fe8f45cb9df
3Author: bitbucket
4Date: Fri Dec 1 15:03:07 2017 -0800
5prepend content to reset_lifecycle_file
6
7commit dc67808a6da9f0dec51ed16d3d8823f28e1a72a
8Author: bitbucket
9Date: Fri Dec 1 10:21:57 2017 -0800
10
11update content of reset_lifecycle_file
12
13commit 780411da3b47117270c0e3a8d5dcfd11d28d04a4
14
15Author: bitbucket
16Date: Thu Nov 30 16:50:39 2017 -0800
17
18initial commit
```
Ten en cuenta que los ID del historial de confirmaciones serán únicos en cada sistema. Esto significa que los ID de confirmación de este ejemplo serán diferentes de los que veas en tu dispositivo. El ID de confirmación que nos interesa para este ejemplo es `780411da3b47117270c0e3a8d5dcfd11d28d04a4`. Es el ID que corresponde a la confirmación inicial (initial commit). Una vez que hayamos localizado este ID, lo utilizaremos como objetivo de nuestro soft reset.
Antes de retroceder en el tiempo, vamos a comprobar primero el estado actual del repositorio.
```
1$ git status && git ls-files -s
2On branch main
3nothing to commit, working tree clean
4100644 67cc52710639e5da6b515416fd779d0741e3762e 0 reset_lifecycle_file
```
Aquí ejecutamos un comando combinado de `git status y git ls-files -s` que nos muestra que hay cambios pendientes en el repositorio y que `reset_lifecycle_file` del índice del entorno de ensayo se encuentra en una versión de `67cc52710639e5da6b515416fd779d0741e3762e`. Teniendo esto en cuenta, vamos a ejecutar un soft reset a nuestra primera confirmación.
```
1$git reset --soft 780411da3b47117270c0e3a8d5dcfd11d28d04a4
2$ git status && git ls-files -s
3On branch main
4Changes to be committed:
5 (use "git reset HEAD ..." to unstage)
6
7modified: reset_lifecycle_file
8100644 67cc52710639e5da6b515416fd779d0741e3762e 0 reset_lifecycle_file
```
El código anterior ejecuta un "soft reset" y también invoca el comando combinado `git status` y `git ls-files`, que muestra el resultado del estado del repositorio. Podemos examinar el resultado del estado del repositorio y sacar algunas observaciones interesantes. En primer lugar, `git status` indica que hay modificaciones en `reset_lifecycle_file` y las resalta indicando que son cambios preparados para la siguiente confirmación. En segundo lugar, la información de `git ls-files` indica que el índice del entorno de ensayo no ha cambiado y conserva el SHA zero-width 67cc52710639e5da6b515416fd779d0741e3762e que teníamos antes.
Para explicar mejor lo que ha ocurrido en este restablecimiento, vamos a examinar el `git log`:
```
1$ git log commit 780411da3b47117270c0e3a8d5dcfd11d28d04a4 Author: bitbucket Date: Thu Nov 30 16:50:39 2017 -0800 initial commit
```
El resultado del registro ahora muestra que hay una única confirmación en el historial de confirmaciones. Esto ayuda a ilustrar claramente qué ha hecho `--soft`. Como sucede en todas las invocaciones de `git reset`, lo primero que hace el restablecimiento es restablecer el árbol de confirmaciones. Los dos ejemplos anteriores con `--hard` y `--mixed` han apuntado a `HEAD` y no han hecho que el árbol de confirmaciones retroceda en el tiempo. Durante un soft reset, esto es lo único que sucede.
Entonces, podríamos preguntarnos por qué `git status` indica que hay archivos modificados. `--soft` no toca el índice del entorno de ensayo, por lo que las actualizaciones de este nos han acompañado en el tiempo a lo largo del historial de confirmaciones. Podemos confirmarlo con el resultado de `git ls-files -s`, que muestra que no ha cambiado el SHA de `reset_lifecycle_file`. Como recordatorio, `git status` no muestra el estado de "los tres árboles", sino que, en esencia, muestra una comparación entre ellos. En este caso, muestra que el índice del entorno de ensayo va por delante de los cambios del historial de confirmaciones como si ya los hubiéramos preparado.
## Diferencia entre restablecer y revertir
Si [git revert](https://www.atlassian.com/es/git/tutorials/undoing-changes/git-revert) es una forma "segura" de deshacer los cambios, podríamos considerar `git reset` como el método peligroso. Corremos el riesgo real de perder trabajo con `git reset`. `git reset` nunca eliminará una confirmación. Sin embargo, las confirmaciones pueden quedarse "huérfanas", es decir, sin una ruta directa desde una referencia para acceder a ellas. Normalmente estas confirmaciones huérfanas pueden localizarse y restaurarse utilizando [git reflog](https://www.atlassian.com/es/git/tutorials/rewriting-history/git-reflog). Git eliminará para siempre las confirmaciones huérfanas tras ejecutar el recolector de basura interno. De manera predeterminada, Git está configurado para ejecutar el recolector de basura cada 30 días. El historial de confirmaciones es uno de los "tres árboles de Git"; los otros dos, el índice del entorno de ensayo y el directorio de trabajo, no son tan permanentes como las confirmaciones. Se debe tener cuidado al utilizar esta herramienta, ya que es uno de los únicos comandos de Git que puede hacerte perder el trabajo realizado.
Mientras que la reversión se ha diseñado para deshacer de forma segura una confirmación pública, `git reset` se ha diseñado para deshacer los cambios locales en el índice del entorno de ensayo y el directorio de trabajo. Dado que sus objetivos son diferentes, los dos comandos se implementan de forma distinta: el restablecimiento elimina por completo un conjunto de cambios, mientras que la reversión conserva el conjunto de cambios original y utiliza una nueva confirmación para aplicar la acción de deshacer.
## No restablezcas el historial público
No deberías utilizar nunca `git reset <commit>` si se ha enviado alguna instantánea posterior a `<commit>` a un repositorio público. Después de publicar una confirmación, tienes que dar por sentado que el resto de los desarrolladores dependen de ella.
Eliminar una confirmación que otros miembros del equipo han seguido desarrollando supone un problema grave para la colaboración. Cuando intenten sincronizarse con tu repositorio, parecerá que un pedazo del historial del proyecto ha desaparecido repentinamente. En la secuencia que aparece abajo se muestra lo que ocurre cuando intentas restablecer una confirmación pública. La rama `origin/main` es la versión de tu rama `main` local del repositorio central.

En cuanto añadas nuevas confirmaciones tras el restablecimiento, Git creerá que tu historial local se ha desviado de `origin/main`, y es probable que la confirmación de fusión necesaria para sincronizar tus repositorios confunda y frustre a tu equipo.
Lo importante es que te asegures de que estás utilizando `git reset <commit>` en un experimento local que salió mal, no en cambios publicados. Si tienes que arreglar una confirmación pública, el comando `git revert` se ha diseñado específicamente para este fin.
## Ejemplos
```
1git reset <file>
```
Elimina el archivo especificado del entorno de ensayo, pero el directorio de trabajo se mantiene intacto. Deshace la preparación de un archivo sin sobrescribir ninguno de los cambios.
```
1git reset
```
Restablece el entorno de ensayo para que refleje la confirmación más reciente, pero el directorio de trabajo se mantiene intacto. Deshace la preparación de todos los archivos sin sobrescribir ninguno de los cambios, lo que te da la oportunidad de volver a compilar la instantánea preparada desde cero.
```
1git reset --hard
```
Restablece el entorno de ensayo y el directorio de trabajo para que reflejen la confirmación más reciente. Además de deshacer la preparación de los cambios, el indicador `--hard` le indica a Git que sobrescriba todos los cambios en el directorio de trabajo también. Dicho de otra manera: borra todos los cambios no confirmados, así que asegúrate de que realmente quieres descartar tus desarrollos locales antes de utilizarlo.
```
1git reset
```
Retrocede el extremo de la rama actual a `commit`, restablece el entorno de ensayo para que coincida, pero no toques el directorio de trabajo. Todos los cambios realizados desde `<commit>` se encontrarán en el directorio de trabajo, que te permite volver a confirmar el historial del proyecto utilizando instantáneas más limpias y más atómicas.
```
1git reset --hard
```
Retrocede el extremo de la rama actual a `<commit>` y restablece tanto el entorno de ensayo como el directorio de trabajo para que coincidan. Esta acción elimina no solo los cambios no confirmados, sino también todas las confirmaciones posteriores.
## Cómo deshacer la preparación de un archivo
El comando `git reset` suele aparecer mientras se prepara la instantánea preparada. En el siguiente ejemplo, se da por supuesto que tienes dos archivos llamados `hello.py` y `main.py` que ya has añadido al repositorio.
```
1# Edit both hello.py and main.py
2
3# Stage everything in the current directory
4git add .
5
6# Realize that the changes in hello.py and main.py
7# should be committed in different snapshots
8
9# Unstage main.py
10git reset main.py
11
12# Commit only hello.py
13git commit -m "Make some changes to hello.py"
14
15# Commit main.py in a separate snapshot
16git add main.py
17git commit -m "Edit main.py"
```
Como puedes ver, `git reset` te ayudar a mantener tus confirmaciones con un enfoque muy claro al permitirte deshacer la preparación de los cambios que no están relacionados con la siguiente confirmación.
## Eliminación de las confirmaciones locales
El siguiente ejemplo muestra un caso práctico más avanzado. Demuestra qué sucede cuando has estado trabajando en un nuevo experimento durante un tiempo, pero decides descartarlo por completo tras confirmar unas cuantas instantáneas.
```
1# Create a new file called `foo.py` and add some code to it
2
3# Commit it to the project history
4git add foo.py
5git commit -m "Start developing a crazy feature"
6
7# Edit `foo.py` again and change some other tracked files, too
8
9# Commit another snapshot
10git commit -a -m "Continue my crazy feature"
11
12# Decide to scrap the feature and remove the associated commits
13git reset --hard HEAD~2
```
El comando `git reset HEAD~2` retrocede la rama actual dos confirmaciones, con lo que se elimina de forma eficaz las dos instantáneas que acabamos de crear a partir del historial del proyecto. Recuerda que este tipo de restablecimiento solo debe utilizarse en las confirmaciones no publicadas. No hagas nunca la operación anterior si ya has enviado tus confirmaciones a un repositorio compartido.
## Resumen
Como resumen, `git reset` es un comando potente que sirve para deshacer los cambios locales en el estado de un repositorio de Git. `git reset` actúa en "los tres árboles de Git". Estos árboles son el historial de confirmaciones (`HEAD`), el índice del entorno de ensayo y el directorio de trabajo. Hay tres opciones de líneas de comandos que se corresponden con los tres árboles. Las opciones `--soft, --mixed` y `--hard` se pueden pasar a `git reset`.
En este artículo, hemos utilizado unos cuantos comandos distintos de Git para ayudar a mostrar los procesos de restablecimiento. Amplía la información sobre esos comandos en las siguientes páginas individuales: [git status](https://www.atlassian.com/es/git/tutorials/inspecting-a-repository), [git log](https://www.atlassian.com/es/git/tutorials/git-log), [git add](https://www.atlassian.com/es/git/tutorials/saving-changes), [git checkout](https://www.atlassian.com/es/git/tutorials/using-branches/git-checkout), [git reflog](https://www.atlassian.com/es/git/tutorials/rewriting-history/git-reflog) y [git revert](https://www.atlassian.com/es/git/tutorials/undoing-changes/git-revert).
## Recomendado para ti
### Blog de Bitbucket
[Más información](https://www.atlassian.com/blog/bitbucket)
### Ruta de aprendizaje de DevOps
[Más información](https://university.atlassian.com/student/activity/2483065-hello-and-welcome)
### Más información sobre Git
Encuentra más guías y recursos de Git en este centro.
[Lee más](https://www.atlassian.com/es/git)
- [Compañía](https://www.atlassian.com/es/company)
- [Oportunidades profesionales](https://www.atlassian.com/es/company/careers)
- [Eventos](https://www.atlassian.com/es/company/events)
- [Blogs](https://www.atlassian.com/es/blog)
- [Relaciones con los inversores](https://investors.atlassian.com/)
- [Atlassian Foundation](https://www.atlassianfoundation.org/)
- [Kit de prensa](https://www.atlassian.com/es/company/news/press-kit)
- [Contacto](https://www.atlassian.com/es/company/contact)
## Productos
- [Rovo](https://www.atlassian.com/es/rovo)
- [Jira](https://www.atlassian.com/es/software/jira)
- [Jira Align](https://www.atlassian.com/es/software/jira/align)
- [Jira Service Management](https://www.atlassian.com/es/software/jira/service-management)
- [Confluence](https://www.atlassian.com/es/software/confluence)
- [Loom](https://www.atlassian.com/es/software/loom)
- [Trello](https://trello.com/es/home)
- [Bitbucket](https://www.atlassian.com/es/software/bitbucket)
- [Ver todos los productos](https://www.atlassian.com/es/software)
## Recursos
- [Servicio técnico](https://support.atlassian.com/)
- [Compras y licencias](https://www.atlassian.com/es/licensing/purchase-licensing)
- [Comunidad de Atlassian](https://community.atlassian.com/)
- [Base de conocimientos](https://confluence.atlassian.com/kb)
- [Marketplace](https://marketplace.atlassian.com/)
- [Mi cuenta](https://my.atlassian.com/products/index)
- [Crear ticket de asistencia](https://support.atlassian.com/contact/)
## Tutorial
- [Partners](https://www.atlassian.com/es/partners)
- [Formación y certificación](https://www.atlassian.com/es/university)
- [Documentación](https://confluence.atlassian.com/display/ALLDOC/Atlassian+Documentation)
- [Recursos para desarrolladores](https://www.atlassian.com/es/developers)
- [Servicios empresariales](https://www.atlassian.com/es/enterprise/services)
- [Ver todos los recursos](https://www.atlassian.com/es/resources)
Copyright © 2026 Atlassian
- [Política de privacidad](https://www.atlassian.com/es/legal/privacy-policy)
- [Aviso de recopilación de datos](https://www.atlassian.com/legal/privacy-policy#additional-disclosures-for-ca-residents)
- [Términos](https://www.atlassian.com/es/legal/cloud-terms-of-service)
- [Aviso legal](https://www.atlassian.com/es/legal/impressum)
Selector de idioma
Español
▾ |
| Readable Markdown | El comando `git reset` es una herramienta compleja y versátil para deshacer cambios. Se invoca principalmente de tres formas distintas, que se corresponden con los argumentos de líneas de comandos `--soft, --mixed y --hard`. Cada uno de los tres argumentos se corresponde con los tres mecanismos de gestión de estados internos de Git: el árbol de confirmaciones (`HEAD`), el índice del entorno de ensayo y el directorio de trabajo.
Git reset y los tres árboles de Git
Para entender correctamente cómo utilizar `git reset`, primero tenemos que entender los sistemas de gestión de estados internos de Git. A veces, a estos mecanismos se les llama los "tres árboles" de Git. Puede que este nombre sea poco apropiado, ya que no son estrictamente estructuras de datos tradicionales en forma de árbol. Sin embargo, son estructuras de datos de nodos y basadas en punteros que Git utiliza para monitorizar un cronograma de ediciones. La mejor manera de demostrar estos mecanismos es crear un conjunto de cambios en un repositorio y seguirlo a lo largo de los tres árboles.
Para empezar, crearemos un nuevo repositorio con los siguientes comandos:
```
$ mkdir git_reset_test
$ cd git_reset_test/
$ git init .
Initialized empty Git repository in /git_reset_test/.git/
$ touch reset_lifecycle_file
$ git add reset_lifecycle_file
$ git commit -m"initial commit"
[main (root-commit) d386d86] initial commit
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 reset_lifecycle_file
```
El código de ejemplo anterior crea un nuevo repositorio de Git con un único archivo vacío: `reset_lifecycle_file`. En este punto, el repositorio de ejemplo tiene una única confirmación (`d386d86`) de añadir `reset_lifecycle_file`.
El directorio de trabajo
El primer árbol que examinaremos es "el directorio de trabajo". Este árbol está sincronizado con el sistema de archivos local y representa los cambios inmediatos que se realizan en el contenido de los archivos y los directorios.
```
$ echo 'hello git reset' > reset_lifecycle_file
$ git status
On branch main
Changes not staged for commit:
(use "git add ..." to update what will be committed)
(use "git checkout -- ..." to discard changes in working directory)
modified: reset_lifecycle_file
```
En nuestro repositorio de ejemplo, modificamos y añadimos contenido a `reset_lifecycle_file`. Al invocar `git status`, se muestra que Git está al corriente de los cambios en el archivo. En ese momento estos cambios forman parte del primer árbol: "el directorio de trabajo". `git status` puede utilizarse para mostrar los cambios en el directorio de trabajo. Se mostrarán en rojo con el prefijo "modified".
Índice del entorno de ensayo
El siguiente es el árbol del "índice del entorno de ensayo". Este árbol monitoriza los cambios en el directorio de trabajo, que se han aplicado con `git add`, para que se almacenen en la siguiente confirmación. Este árbol es un complejo mecanismo de almacenamiento en caché interno. Por lo general, Git intenta ocultar al usuario los pormenores de la implementación del índice del entorno de ensayo.
Para ver con exactitud el estado del índice del entorno de ensayo, debemos utilizar un comando de Git menos conocido: `git ls-files`. El comando `git ls-files` es, básicamente, una utilidad de depuración que sirve para inspeccionar el estado del árbol del índice del entorno de ensayo.
```
git ls-files -s
100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 0 reset_lifecycle_file
```
Aquí hemos ejecutado `git ls-files` con la opción `-s` o `--stage`. Sin la opción `-s`, el resultado de `git ls-files` es simplemente una lista de nombres de archivos y rutas que forman parte del índice en ese momento. La opción `-s` muestra metadatos adicionales de los archivos del índice del entorno de ensayo. Estos metadatos son los bits de modo, el nombre de objeto y el número de entorno del contenido preparado. A nosotros nos interesa el nombre de objeto, el segundo valor (`d7d77c1b04b5edd5acfc85de0b592449e5303770`). Se trata de un hash SHA-1 de objeto de Git estándar. Es un hash del contenido de los archivos. El historial de confirmaciones almacena sus propios SHA de objeto para identificar los punteros de confirmaciones y de referencias, y el índice del entorno de ensayo tiene sus propios SHA de objeto para monitorizar versiones de archivos en el índice.
A continuación, pasaremos el archivo `reset_lifecycle_file` modificado al índice del entorno de ensayo.
```
$ git add reset_lifecycle_file
$ git status
On branch main Changes to be committed:
(use "git reset HEAD ..." to unstage)
modified: reset_lifecycle_file
```
Aquí hemos invocado `git add reset_lifecycle_file` que añade el archivo al índice del entorno de ensayo. Al invocar `git status`, ahora aparece `reset_lifecycle_file` en verde debajo de "Changes to be committed". Conviene resaltar que `git status` no es una representación verdadera del índice del entorno de ensayo. El resultado del comando `git status` muestra los cambios entre el historial de confirmaciones y el índice del entorno de ensayo. Llegados a este punto, vamos a examinar el contenido del índice del entorno de ensayo.
```
$ git ls-files -s 100644 d7d77c1b04b5edd5acfc85de0b592449e5303770 0 reset_lifecycle_file
```
Podemos ver que el SHA de objeto de `reset_lifecycle_file` se ha actualizado de `e69de29bb2d1d6434b8b29ae775ad8c2e48c5391` a `d7d77c1b04b5edd5acfc85de0b592449e5303770`.
Historial de confirmaciones
El último árbol es el historial de confirmaciones. El comando `git commit` añade cambios a una instantánea permanente que reside en el historial de confirmaciones. Esta instantánea también incluye el estado que tenía el índice del entorno de ensayo en el momento de efectuar la confirmación.
```
$ git commit -am"update content of reset_lifecycle_file"
[main dc67808] update content of reset_lifecycle_file
1 file changed, 1 insertion(+)
$ git status
On branch main
nothing to commit, working tree clean
```
Aquí hemos creado una nueva confirmación con el mensaje `"update content of resetlifecyclefile"`. El conjunto de cambios se ha añadido al historial de confirmaciones. Al invocar `git status` en este momento, se muestra que no hay cambios pendientes en ninguno de los árboles. Al ejecutar `git log` se mostrará el historial de confirmaciones. Ahora que hemos seguido la trayectoria de este conjunto de cambios por los tres árboles, podemos empezar a utilizar `git reset`.
Funcionamiento
A nivel superficial, `git reset` tiene un comportamiento parecido a `git checkout`. Mientras que `git checkout` solo opera en el puntero de referencia `HEAD`, `git reset` moverá el puntero de referencia `HEAD` y el puntero de referencia de la rama actual. Para demostrar mejor este comportamiento, vamos a analizar el siguiente ejemplo:

En este ejemplo se muestra una secuencia de confirmaciones en la rama `main`. La referencia `HEAD` y la referencia de la rama `main` en estos momentos apuntan a la confirmación d. Ahora vamos a ejecutar y a comparar tanto `git checkout b` como `git reset b`.
git checkout b

Con `git checkout`, la referencia `main` sigue apuntando a `d`. La referencia `HEAD` se ha movido y ahora apunta a la confirmación `b`. Ahora el repositorio se encuentra en un estado de "`HEAD` desasociado".
git reset b

En comparación, `git reset` mueve tanto las referencias de `HEAD` como las de la rama a la confirmación especificada.
Además de actualizar los punteros de referencia de las confirmaciones, `git reset` modificará el estado de los tres árboles. La modificación del puntero de referencia sucede siempre y es una actualización del tercer árbol, el árbol de confirmaciones. Los argumentos de las líneas de comandos `--soft, --mixed` y `--hard` indican cómo modificar los árboles del índice del entorno de ensayo y del directorio de trabajo.
Opciones principales
La invocación predeterminada de `git reset` tiene argumentos implícitos de `--mixed` y `HEAD`. Esto significa que ejecutar `git reset` equivale a ejecutar `git reset --mixed HEAD`. De esta forma, `HEAD` es la confirmación especificada. En vez de `HEAD`, se puede usar cualquier hash de confirmación SHA-1 de Git.

'--hard
Esta es la opción más directa, PELIGROSA y habitual. Cuando se pasa `--hard`, los punteros de referencia del historial de confirmaciones se actualizan a la confirmación especificada. A continuación, el índice del entorno de ensayo y el directorio de trabajo se restablecen para reflejar la confirmación especificada. Todos los cambios pendientes anteriores del índice del entorno de ensayo y del directorio de trabajo se restablecen para reflejar el estado del árbol de confirmaciones. Esto significa que se perderá cualquier trabajo pendiente que haya quedado en el índice del entorno de ensayo y en el directorio de trabajo.
Para demostrarlo, continuemos con el repositorio de ejemplo de los tres árboles que hemos visto antes. En primer lugar, hagamos unas cuantas modificaciones en el repositorio. Ejecuta los siguientes comandos en el repositorio de ejemplo:
```
$ echo 'new file content' > new_file
$ git add new_file
$ echo 'changed content' >> reset_lifecycle_file
```
Estos comandos han creado un nuevo archivo llamado `new_file` y lo han añadido al repositorio. Además, se modificará el contenido de `reset_lifecycle_file`. Ahora que se han aplicado estos cambios, examinemos el estado del repositorio usando `git status`.
```
$ git status
On branch main
Changes to be committed:
(use "git reset HEAD ..." to unstage)
new file: new_file
Changes not staged for commit:
(use "git add ..." to update what will be committed)
(use "git checkout -- ..." to discard changes in working directory)
modified: reset_lifecycle_file
```
Aquí hemos invocado `git add reset_lifecycle_file` que añade el archivo al índice del entorno de ensayo. Al invocar `git status`, ahora aparece `reset_lifecycle_file` en verde debajo de "Changes to be committed". Conviene resaltar que `git status` no es una representación verdadera del índice del entorno de ensayo. El resultado del comando `git status` muestra los cambios entre el historial de confirmaciones y el índice del entorno de ensayo. Llegados a este punto, vamos a examinar el contenido del índice del entorno de ensayo.
```
$ git ls-files -s
100644 8e66654a5477b1bf4765946147c49509a431f963 0 new_file
100644 d7d77c1b04b5edd5acfc85de0b592449e5303770 0 reset_lifecycle_file
```
Podemos ver que `new_file` se ha añadido al índice. Hemos efectuado modificaciones en `reset_lifecycle_file`, pero el SHA del índice del entorno de ensayo (`d7d77c1b04b5edd5acfc85de0b592449e5303770`) sigue siendo el mismo. Este es un comportamiento previsto, ya que no se ha usado `git add` para aplicar estos cambios en el índice del entorno de ensayo. Estos cambios existen en el directorio de trabajo.
Ahora vamos a ejecutar un comando `git reset --hard` y a examinar el nuevo estado del repositorio.
```
$ git reset --hard
HEAD is now at dc67808 update content of reset_lifecycle_file
$ git status
On branch main
nothing to commit, working tree clean
$ git ls-files -s
100644 d7d77c1b04b5edd5acfc85de0b592449e5303770 0 reset_lifecycle_file
```
Aquí hemos ejecutado un "hard reset" utilizando la opción `--hard`. Git muestra el resultado indicando que `HEAD` apunta a la última confirmación `dc67808`. A continuación, comprobamos el estado del repositorio con `git status`. Git indica que no hay cambios pendientes. Examinamos también el estado del índice del entorno de ensayo y vemos que se ha restablecido a un punto anterior a que se añadiera `new_file`. Nuestras modificaciones en `reset_lifecycle_file` y la adición de `new_file` se han destruido. Esta pérdida de datos no se puede deshacer. Es esencial que tomemos buena nota de ello.
'--mixed
Este es el modo de funcionamiento predeterminado. Se actualizan los punteros de referencia. El índice del entorno de ensayo se restablece al estado de la confirmación especificada. Todos los cambios que se hayan deshecho en el índice del entorno de ensayo se mueven al directorio de trabajo. Vamos a continuar.
```
$ echo 'new file content' > new_file
$ git add new_file
$ echo 'append content' >> reset_lifecycle_file
$ git add reset_lifecycle_file
$ git status
On branch main
Changes to be committed:
(use "git reset HEAD ..." to unstage)
new file: new_file
modified: reset_lifecycle_file
$ git ls-files -s
100644 8e66654a5477b1bf4765946147c49509a431f963 0 new_file
100644 7ab362db063f9e9426901092c00a3394b4bec53d 0 reset_lifecycle_file
```
En el ejemplo anterior, hemos hecho unas cuantas modificaciones en el repositorio. De nuevo, hemos añadido un `new_file` y modificado el contenido de `reset_lifecycle_file`. A continuación, estos cambios se aplican al índice del entorno de ensayo con `git add`. Con el repositorio en este estado, ejecutaremos ahora el restablecimiento.
```
$ git reset --mixed
$ git status
On branch main
Changes not staged for commit:
(use "git add ..." to update what will be committed)
(use "git checkout -- ..." to discard changes in working directory)
modified: reset_lifecycle_file
Untracked files:
(use "git add ..." to include in what will be committed)
new_file
no changes added to commit (use "git add" and/or "git commit -a")
$ git ls-files -s
100644 d7d77c1b04b5edd5acfc85de0b592449e5303770 0 reset_lifecycle_file
```
Aquí hemos ejecutado un "mixed reset". Para que quede claro, `--mixed` es el modo predeterminado y surte el mismo efecto que ejecutar `git reset`. Al examinar el resultado de `git status` y `git ls-files`, se ve que el índice del entorno de ensayo se ha restablecido a un estado en el que `reset_lifecycle_file` es el único archivo del índice. El SHA de objeto de `reset_lifecycle_file` se ha restablecido a la versión anterior.
Lo importante que debemos destacar aquí es que `git status` nos muestra que hay modificaciones en `reset_lifecycle_file` y que hay un archivo sin seguimiento: `new_file`. Este es el comportamiento `--mixed` explícito. Se ha restablecido el índice del entorno de ensayo y se han movido los cambios pendientes al directorio de trabajo. Solo tienes que compararlo con el caso del `--hard` reset, en el que se restablecieron tanto el índice del entorno de ensayo como el directorio de trabajo, lo que hizo que se perdieran estas actualizaciones.
'--soft
Cuando se pasa el argumento `--soft`, se actualizan los punteros de referencia y el restablecimiento se detiene ahí. El índice del entorno de ensayo y el directorio de trabajo permanecen intactos. Puede ser difícil demostrar claramente este comportamiento. Vamos a continuar con nuestro repositorio demo y a prepararlo para un soft reset.
```
$ git add reset_lifecycle_file
$ git ls-files -s
100644 67cc52710639e5da6b515416fd779d0741e3762e 0 reset_lifecycle_file
$ git status
On branch main
Changes to be committed:
(use "git reset HEAD ..." to unstage)
modified: reset_lifecycle_file
Untracked files:
(use "git add ..." to include in what will be committed)
new_file
```
Aquí hemos utilizado otra vez `git add` para pasar el `reset_lifecycle_file` modificado al índice del entorno de ensayo. Confirmamos que el índice se ha actualizado con el resultado de `git ls-files`. El resultado de `git status` ahora muestra "Changes to be committed" en verde. El `new_file` de nuestros ejemplos anteriores está flotando por el directorio de trabajo como un archivo sin seguimiento. Vamos a ejecutar rápidamente `rm new_file` para eliminar el archivo, puesto que no lo necesitaremos para los siguientes ejemplos.
Con el repositorio en este estado, ejecutaremos ahora un restablecimiento parcial (soft reset).
```
$ git reset --soft
$ git status
On branch main
Changes to be committed:
(use "git reset HEAD ..." to unstage)
modified: reset_lifecycle_file
$ git ls-files -s
100644 67cc52710639e5da6b515416fd779d0741e3762e 0 reset_lifecycle_file
```
Hemos ejecutado un "soft reset". Al examinar el estado del repositorio con `git status` y `git ls-files`, se muestra que no ha cambiado nada. Es un comportamiento esperado. Un soft reset solo restablecerá el historial de confirmaciones. De manera predeterminada, `git reset` se invoca con `HEAD` como la confirmación objetivo. Como nuestro historial de confirmaciones ya se encontraba en `HEAD` y restablecemos implícitamente a `HEAD`, no ha ocurrido nada en realidad.
Para entender y utilizar mejor `--soft`, necesitamos una confirmación objetivo que no sea `HEAD`. Tenemos a `reset_lifecycle_file` en espera en el índice del entorno de ensayo. Vamos a crear una nueva confirmación.
```
$ git commit -m"prepend content to reset_lifecycle_file"
```
En este punto, nuestro repositorio debería tener tres confirmaciones. Retrocederemos en el tiempo hasta la primera de ellas. Para ello, necesitaremos el ID de la primera confirmación. Se puede saber viendo el resultado desde `git log`.
```
$ git log
commit 62e793f6941c7e0d4ad9a1345a175fe8f45cb9df
Author: bitbucket
Date: Fri Dec 1 15:03:07 2017 -0800
prepend content to reset_lifecycle_file
commit dc67808a6da9f0dec51ed16d3d8823f28e1a72a
Author: bitbucket
Date: Fri Dec 1 10:21:57 2017 -0800
update content of reset_lifecycle_file
commit 780411da3b47117270c0e3a8d5dcfd11d28d04a4
Author: bitbucket
Date: Thu Nov 30 16:50:39 2017 -0800
initial commit
```
Ten en cuenta que los ID del historial de confirmaciones serán únicos en cada sistema. Esto significa que los ID de confirmación de este ejemplo serán diferentes de los que veas en tu dispositivo. El ID de confirmación que nos interesa para este ejemplo es `780411da3b47117270c0e3a8d5dcfd11d28d04a4`. Es el ID que corresponde a la confirmación inicial (initial commit). Una vez que hayamos localizado este ID, lo utilizaremos como objetivo de nuestro soft reset.
Antes de retroceder en el tiempo, vamos a comprobar primero el estado actual del repositorio.
```
$ git status && git ls-files -s
On branch main
nothing to commit, working tree clean
100644 67cc52710639e5da6b515416fd779d0741e3762e 0 reset_lifecycle_file
```
Aquí ejecutamos un comando combinado de `git status y git ls-files -s` que nos muestra que hay cambios pendientes en el repositorio y que `reset_lifecycle_file` del índice del entorno de ensayo se encuentra en una versión de `67cc52710639e5da6b515416fd779d0741e3762e`. Teniendo esto en cuenta, vamos a ejecutar un soft reset a nuestra primera confirmación.
```
$git reset --soft 780411da3b47117270c0e3a8d5dcfd11d28d04a4
$ git status && git ls-files -s
On branch main
Changes to be committed:
(use "git reset HEAD ..." to unstage)
modified: reset_lifecycle_file
100644 67cc52710639e5da6b515416fd779d0741e3762e 0 reset_lifecycle_file
```
El código anterior ejecuta un "soft reset" y también invoca el comando combinado `git status` y `git ls-files`, que muestra el resultado del estado del repositorio. Podemos examinar el resultado del estado del repositorio y sacar algunas observaciones interesantes. En primer lugar, `git status` indica que hay modificaciones en `reset_lifecycle_file` y las resalta indicando que son cambios preparados para la siguiente confirmación. En segundo lugar, la información de `git ls-files` indica que el índice del entorno de ensayo no ha cambiado y conserva el SHA zero-width 67cc52710639e5da6b515416fd779d0741e3762e que teníamos antes.
Para explicar mejor lo que ha ocurrido en este restablecimiento, vamos a examinar el `git log`:
```
$ git log commit 780411da3b47117270c0e3a8d5dcfd11d28d04a4 Author: bitbucket Date: Thu Nov 30 16:50:39 2017 -0800 initial commit
```
El resultado del registro ahora muestra que hay una única confirmación en el historial de confirmaciones. Esto ayuda a ilustrar claramente qué ha hecho `--soft`. Como sucede en todas las invocaciones de `git reset`, lo primero que hace el restablecimiento es restablecer el árbol de confirmaciones. Los dos ejemplos anteriores con `--hard` y `--mixed` han apuntado a `HEAD` y no han hecho que el árbol de confirmaciones retroceda en el tiempo. Durante un soft reset, esto es lo único que sucede.
Entonces, podríamos preguntarnos por qué `git status` indica que hay archivos modificados. `--soft` no toca el índice del entorno de ensayo, por lo que las actualizaciones de este nos han acompañado en el tiempo a lo largo del historial de confirmaciones. Podemos confirmarlo con el resultado de `git ls-files -s`, que muestra que no ha cambiado el SHA de `reset_lifecycle_file`. Como recordatorio, `git status` no muestra el estado de "los tres árboles", sino que, en esencia, muestra una comparación entre ellos. En este caso, muestra que el índice del entorno de ensayo va por delante de los cambios del historial de confirmaciones como si ya los hubiéramos preparado.
Diferencia entre restablecer y revertir
Si [git revert](https://www.atlassian.com/es/git/tutorials/undoing-changes/git-revert) es una forma "segura" de deshacer los cambios, podríamos considerar `git reset` como el método peligroso. Corremos el riesgo real de perder trabajo con `git reset`. `git reset` nunca eliminará una confirmación. Sin embargo, las confirmaciones pueden quedarse "huérfanas", es decir, sin una ruta directa desde una referencia para acceder a ellas. Normalmente estas confirmaciones huérfanas pueden localizarse y restaurarse utilizando [git reflog](https://www.atlassian.com/es/git/tutorials/rewriting-history/git-reflog). Git eliminará para siempre las confirmaciones huérfanas tras ejecutar el recolector de basura interno. De manera predeterminada, Git está configurado para ejecutar el recolector de basura cada 30 días. El historial de confirmaciones es uno de los "tres árboles de Git"; los otros dos, el índice del entorno de ensayo y el directorio de trabajo, no son tan permanentes como las confirmaciones. Se debe tener cuidado al utilizar esta herramienta, ya que es uno de los únicos comandos de Git que puede hacerte perder el trabajo realizado.
Mientras que la reversión se ha diseñado para deshacer de forma segura una confirmación pública, `git reset` se ha diseñado para deshacer los cambios locales en el índice del entorno de ensayo y el directorio de trabajo. Dado que sus objetivos son diferentes, los dos comandos se implementan de forma distinta: el restablecimiento elimina por completo un conjunto de cambios, mientras que la reversión conserva el conjunto de cambios original y utiliza una nueva confirmación para aplicar la acción de deshacer.
No restablezcas el historial público
No deberías utilizar nunca `git reset <commit>` si se ha enviado alguna instantánea posterior a `<commit>` a un repositorio público. Después de publicar una confirmación, tienes que dar por sentado que el resto de los desarrolladores dependen de ella.
Eliminar una confirmación que otros miembros del equipo han seguido desarrollando supone un problema grave para la colaboración. Cuando intenten sincronizarse con tu repositorio, parecerá que un pedazo del historial del proyecto ha desaparecido repentinamente. En la secuencia que aparece abajo se muestra lo que ocurre cuando intentas restablecer una confirmación pública. La rama `origin/main` es la versión de tu rama `main` local del repositorio central.

En cuanto añadas nuevas confirmaciones tras el restablecimiento, Git creerá que tu historial local se ha desviado de `origin/main`, y es probable que la confirmación de fusión necesaria para sincronizar tus repositorios confunda y frustre a tu equipo.
Lo importante es que te asegures de que estás utilizando `git reset <commit>` en un experimento local que salió mal, no en cambios publicados. Si tienes que arreglar una confirmación pública, el comando `git revert` se ha diseñado específicamente para este fin.
Ejemplos
```
git reset <file>
```
Elimina el archivo especificado del entorno de ensayo, pero el directorio de trabajo se mantiene intacto. Deshace la preparación de un archivo sin sobrescribir ninguno de los cambios.
```
git reset
```
Restablece el entorno de ensayo para que refleje la confirmación más reciente, pero el directorio de trabajo se mantiene intacto. Deshace la preparación de todos los archivos sin sobrescribir ninguno de los cambios, lo que te da la oportunidad de volver a compilar la instantánea preparada desde cero.
```
git reset --hard
```
Restablece el entorno de ensayo y el directorio de trabajo para que reflejen la confirmación más reciente. Además de deshacer la preparación de los cambios, el indicador `--hard` le indica a Git que sobrescriba todos los cambios en el directorio de trabajo también. Dicho de otra manera: borra todos los cambios no confirmados, así que asegúrate de que realmente quieres descartar tus desarrollos locales antes de utilizarlo.
```
git reset
```
Retrocede el extremo de la rama actual a `commit`, restablece el entorno de ensayo para que coincida, pero no toques el directorio de trabajo. Todos los cambios realizados desde `<commit>` se encontrarán en el directorio de trabajo, que te permite volver a confirmar el historial del proyecto utilizando instantáneas más limpias y más atómicas.
```
git reset --hard
```
Retrocede el extremo de la rama actual a `<commit>` y restablece tanto el entorno de ensayo como el directorio de trabajo para que coincidan. Esta acción elimina no solo los cambios no confirmados, sino también todas las confirmaciones posteriores.
Cómo deshacer la preparación de un archivo
El comando `git reset` suele aparecer mientras se prepara la instantánea preparada. En el siguiente ejemplo, se da por supuesto que tienes dos archivos llamados `hello.py` y `main.py` que ya has añadido al repositorio.
```
# Edit both hello.py and main.py
# Stage everything in the current directory
git add .
# Realize that the changes in hello.py and main.py
# should be committed in different snapshots
# Unstage main.py
git reset main.py
# Commit only hello.py
git commit -m "Make some changes to hello.py"
# Commit main.py in a separate snapshot
git add main.py
git commit -m "Edit main.py"
```
Como puedes ver, `git reset` te ayudar a mantener tus confirmaciones con un enfoque muy claro al permitirte deshacer la preparación de los cambios que no están relacionados con la siguiente confirmación.
Eliminación de las confirmaciones locales
El siguiente ejemplo muestra un caso práctico más avanzado. Demuestra qué sucede cuando has estado trabajando en un nuevo experimento durante un tiempo, pero decides descartarlo por completo tras confirmar unas cuantas instantáneas.
```
# Create a new file called `foo.py` and add some code to it
# Commit it to the project history
git add foo.py
git commit -m "Start developing a crazy feature"
# Edit `foo.py` again and change some other tracked files, too
# Commit another snapshot
git commit -a -m "Continue my crazy feature"
# Decide to scrap the feature and remove the associated commits
git reset --hard HEAD~2
```
El comando `git reset HEAD~2` retrocede la rama actual dos confirmaciones, con lo que se elimina de forma eficaz las dos instantáneas que acabamos de crear a partir del historial del proyecto. Recuerda que este tipo de restablecimiento solo debe utilizarse en las confirmaciones no publicadas. No hagas nunca la operación anterior si ya has enviado tus confirmaciones a un repositorio compartido.
Resumen
Como resumen, `git reset` es un comando potente que sirve para deshacer los cambios locales en el estado de un repositorio de Git. `git reset` actúa en "los tres árboles de Git". Estos árboles son el historial de confirmaciones (`HEAD`), el índice del entorno de ensayo y el directorio de trabajo. Hay tres opciones de líneas de comandos que se corresponden con los tres árboles. Las opciones `--soft, --mixed` y `--hard` se pueden pasar a `git reset`.
En este artículo, hemos utilizado unos cuantos comandos distintos de Git para ayudar a mostrar los procesos de restablecimiento. Amplía la información sobre esos comandos en las siguientes páginas individuales: [git status](https://www.atlassian.com/es/git/tutorials/inspecting-a-repository), [git log](https://www.atlassian.com/es/git/tutorials/git-log), [git add](https://www.atlassian.com/es/git/tutorials/saving-changes), [git checkout](https://www.atlassian.com/es/git/tutorials/using-branches/git-checkout), [git reflog](https://www.atlassian.com/es/git/tutorials/rewriting-history/git-reflog) y [git revert](https://www.atlassian.com/es/git/tutorials/undoing-changes/git-revert). |
| Shard | 44 (laksa) |
| Root Hash | 11161217235333269644 |
| Unparsed URL | com,atlassian!www,/es/git/tutorials/undoing-changes/git-reset s443 |