🕷️ Crawler Inspector

URL Lookup

Direct Parameter Lookup

Raw Queries and Responses

1. Shard Calculation

Query:
Response:
Calculated Shard: 44 (from laksa073)

2. Crawled Status Check

Query:
Response:

3. Robots.txt Check

Query:
Response:

4. Spam/Ban Check

Query:
Response:

5. Seen Status Check

ℹ️ Skipped - page is already crawled

📄
INDEXABLE
CRAWLED
12 days ago
🤖
ROBOTS ALLOWED

Page Info Filters

FilterStatusConditionDetails
HTTP statusPASSdownload_http_code = 200HTTP 200
Age cutoffPASSdownload_stamp > now() - 6 MONTH0.4 months ago
History dropPASSisNull(history_drop_reason)No drop reason
Spam/banPASSfh_dont_index != 1 AND ml_spam_score = 0ml_spam_score=0
CanonicalPASSmeta_canonical IS NULL OR = '' OR = src_unparsedNot set

Page Details

PropertyValue
URLhttps://www.atlassian.com/es/git/tutorials/undoing-changes/git-reset
Last Crawled2026-04-01 14:50:43 (12 days ago)
First Indexed2019-07-21 06:59:19 (6 years ago)
HTTP Status Code200
Meta TitleGit reset | Tutorial de Atlassian sobre Git
Meta Descriptiongit 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 Canonicalnull
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: ![4 nodos en los que el nodo main es el último](https://dam-cdn.atl.orangelogic.com/AssetLink/q20k742yfq646i283f4x6rrk16iddpe5.png) 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 ![4 nodos con el main apuntando al último y HEAD apuntando al segundo nodo](https://dam-cdn.atl.orangelogic.com/AssetLink/0g7p8ct5r76ko7b642t6ug4654i0315j.png) 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 ![2 conjuntos de 2 nodos con HEAD/main apuntando al segundo del primer conjunto](https://dam-cdn.atl.orangelogic.com/AssetLink/vo1o8v4ewv1556wr171a3j2k03g55b2o.png) 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. ![diagrama del alcance de los restablecimientos de git](https://dam-cdn.atl.orangelogic.com/AssetLink/w38j1kkm86l1vlrs0ih055vr6amf40tw.svg) ## '--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. ![Diagrama de lo que ocurre tras el restablecimiento: da como resultado dos ramas main](https://dam-cdn.atl.orangelogic.com/AssetLink/AT21JD7.svg) 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: ![4 nodos en los que el nodo main es el último](https://dam-cdn.atl.orangelogic.com/AssetLink/q20k742yfq646i283f4x6rrk16iddpe5.png) 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 ![4 nodos con el main apuntando al último y HEAD apuntando al segundo nodo](https://dam-cdn.atl.orangelogic.com/AssetLink/0g7p8ct5r76ko7b642t6ug4654i0315j.png) 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 ![2 conjuntos de 2 nodos con HEAD/main apuntando al segundo del primer conjunto](https://dam-cdn.atl.orangelogic.com/AssetLink/vo1o8v4ewv1556wr171a3j2k03g55b2o.png) 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. ![diagrama del alcance de los restablecimientos de git](https://dam-cdn.atl.orangelogic.com/AssetLink/w38j1kkm86l1vlrs0ih055vr6amf40tw.svg) '--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. ![Diagrama de lo que ocurre tras el restablecimiento: da como resultado dos ramas main](https://dam-cdn.atl.orangelogic.com/AssetLink/AT21JD7.svg) 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).
Shard44 (laksa)
Root Hash11161217235333269644
Unparsed URLcom,atlassian!www,/es/git/tutorials/undoing-changes/git-reset s443