Una guía para deshacer errores con Git (Parte 2)

 

 

 


Índice
  1. Recuperar una rama eliminada usando Reflog
  2. Mover un compromiso a una rama diferente
  3. Editar el mensaje de una antigua confirmación
  4. Saber deshacer errores es un superpoder

Errores. Estos crueles villanos ni siquiera se detienen en el hermoso mundo del desarrollo de software. Pero aunque no podemos evitar cometer errores, ¡podemos aprender a deshacerlos! Este artículo mostrará las herramientas adecuadas para su trabajo diario con Git. Quizás quieras consultar también el primer artículo de la serie .

 

En esta segunda parte de nuestra serie sobre “Deshacer errores con Git”, volveremos a mirar el peligro a los ojos con valentía: he preparado cuatro nuevos escenarios apocalípticos, ¡incluidas, por supuesto, algunas formas inteligentes de salvarnos el cuello! Pero antes de sumergirnos: echa un vistazo a los artículos anteriores sobre Git para conocer aún más métodos de autorrescate que te ayudarán a deshacer tus errores con Git.

¡Vamos!

Recuperar una rama eliminada usando Reflog

¿Alguna vez eliminaste una rama y, poco después, te diste cuenta de que no deberías haberlo hecho? En el improbable caso de que no conozcas este sentimiento, puedo decirte que no es bueno. Una mezcla de tristeza e ira te invade mientras piensas en todo el trabajo duro que se realizó en las confirmaciones de esa rama, todo el código valioso que ahora has perdido.

Afortunadamente, hay una manera de resucitar esa rama: con la ayuda de una herramienta Git llamada "Reflog". Habíamos utilizado esta herramienta en la primera parte de nuestra serie , pero aquí hay un pequeño repaso: Reflog es como un diario donde Git anota cada movimiento del puntero HEAD en su repositorio local. En otras palabras, menos nerds: cada vez que pagas, confirmas, fusionas, cambias de base, seleccionas, etc., se crea una entrada de diario. ¡Esto hace que Reflog sea una red de seguridad perfecta cuando las cosas van mal!

Veamos un ejemplo concreto:

$ git branch* feature/loginmaster

Podemos ver que actualmente tenemos nuestra sucursal feature/loginregistrada. Digamos que esta es la rama que vamos a eliminar (sin darnos cuenta). Sin embargo, antes de que podamos hacer eso, debemos cambiar a una rama diferente porque no podemos eliminar nuestra rama HEAD actual.

$ git checkout master$ git branch -d feature/login

Nuestra valiosa rama de funciones ya no existe, y le daré un minuto para (a) comprender la gravedad de nuestro error y (b) lamentarse un poco. Después de que hayas enjugado las lágrimas, ¡tenemos que encontrar una manera de recuperar esta rama! Abramos Reflog (simplemente escribiendo git reflog) y veamos qué nos tiene reservado:

Reflog de Git registra todas las acciones principales en nuestro repositorio local. ( Vista previa grande )

 

Aquí hay algunos comentarios que le ayudarán a entender el resultado:

  • En primer lugar, debe saber que Reflog ordena sus entradas cronológicamente: los elementos más recientes se encuentran en la parte superior de la lista.
  • El elemento superior (y por lo tanto el más nuevo) es el git checkoutcomando que ejecutamos antes de eliminar la rama. Se registra aquí en Reflog porque es uno de esos “movimientos del puntero HEAD” que Reflog registra tan diligentemente.
  • Para deshacer nuestro grave error, simplemente podemos regresar al estado anterior , ¡lo cual también está registrado de manera limpia y clara en Reflog!

Así que intentemos esto, creando una nueva rama (con el nombre de nuestra rama "perdida") que comience en este hash SHA-1 del estado "antes":

$ git branch feature/login 776f8ca

¡Y voilá! ¡Estará encantado de ver que ahora hemos restaurado nuestra sucursal aparentemente perdida!

Si estás usando una GUI de escritorio Git como “Tower” , puedes tomar un buen atajo: simplemente presiona CMD+ Zen tu teclado para deshacer el último comando, ¡incluso si acabas de eliminar violentamente una rama!

, una videoteca de 10 horas de Vitaly Friedman. Cientos de ejemplos de la vida real y capacitación de UX en vivo. Vista previa gratuita .

Saltar a la tabla de contenidos ↬

Mover un compromiso a una rama diferente

En muchos equipos, existe un acuerdo para no comprometerse en ramas de larga duración como maino develop: ramas como éstas solo deberían recibir nuevas confirmaciones a través de integraciones (por ejemplo, fusiones o cambios de base). Y, sin embargo, por supuesto, los errores son inevitables: ¡a veces nos olvidamos y, aun así, cometemos en estas ramas! Entonces, ¿cómo podemos limpiar el desastre que hemos causado?

Nuestro compromiso aterrizó en la rama equivocada. ¿Cómo podemos moverlo a su sucursal de destino correcta? ( Vista previa grande )

Por suerte, este tipo de problemas se pueden corregir fácilmente. Arremanguémonos y pongámonos a trabajar.

El primer paso es cambiar a la rama de destino correcta y luego mover la confirmación usando el cherry-pickcomando en exceso:

$ git checkout feature/login$ git cherry-pick 776f8caf

Ahora tendrá el compromiso en la rama deseada, donde debería haber estado en primer lugar. ¡Impresionante!

Pero todavía queda una cosa por hacer: ¡tenemos que limpiar la rama donde aterrizó accidentalmente al principio! El cherry-pickcomando, por así decirlo, creó una copia de la confirmación, pero el original todavía está presente en nuestra rama de larga duración:

Hemos creado con éxito una copia de la confirmación en la rama correcta, pero el original todavía está aquí, en la rama incorrecta. ( Vista previa grande )

Esto significa que tenemos que volver a nuestra rama de larga duración y usar git resetpara eliminarla:

 

$ git checkout main$ git reset --hard HEAD~1

Como puede ver, estamos usando el git resetcomando aquí para borrar la confirmación defectuosa. El HEAD~1parámetro le dice a Git que "regrese 1 revisión detrás de HEAD", borrando efectivamente la confirmación más importante (y en nuestro caso: no deseada) del historial de esa rama. Venta de Minerales

Y listo: el compromiso ahora está donde debería haber estado en primer lugar y nuestra rama de larga duración está limpia, ¡como si nuestro error nunca hubiera ocurrido!

Editar el mensaje de una antigua confirmación

Es muy fácil introducir de contrabando un error tipográfico en un mensaje de confirmación y descubrirlo mucho más tarde. En tal caso, la antigua --amendopción de git commitno se puede utilizar para solucionar este problema, porque solo funciona para la última confirmación. Para corregir cualquier confirmación que sea anterior a esa, tenemos que recurrir a una herramienta de Git llamada “Interactive Rebase”.

Aquí hay un mensaje de confirmación que vale la pena cambiar. ( Vista previa grande )

Primero, tenemos que decirle a Interactive Rebase qué parte del historial de confirmaciones queremos editar. Esto se hace alimentándolo con un hash de confirmación: la confirmación principal del que queremos manipular.

$ git rebase -i 6bcf266b

Luego se abrirá una ventana del editor. Contiene una lista de todas las confirmaciones posteriores a la que proporcionamos como base para la Rebase interactiva en el comando:

El rango de confirmaciones que seleccionamos para editar en nuestra sesión de Interactive Rebase. ( Vista previa grande )

Aquí es importante que no sigas tu primer impulso: en este paso, todavía no editamos el mensaje de confirmación. En cambio, solo le decimos a Git qué tipo de manipulación queremos hacer con cada confirmación. Muy convenientemente, hay una lista de palabras clave de acción anotadas en los comentarios en la parte inferior de esta ventana. Para nuestro caso, marcamos la línea #1 con reword(reemplazando así el estándar pick).

Todo lo que queda por hacer en este paso es guardar y cerrar la ventana del editor. A cambio, se abrirá una nueva ventana del editor que contiene el mensaje actual de la confirmación que marcamos. ¡Y ahora finalmente es el momento de hacer nuestras ediciones!

Aquí tienes todo el proceso de un vistazo:

Constantly fixing small mistakes with “band-aid commits” makes your commit history very hard to read. (Large preview)

This is where fixup comes in. It allows you to still make this correcting band-aid commit. But here comes the magic: it then applies it to the original, broken commit (repairing it that way) and then discards the ugly band-aid commit completely!

Fixup applies your corrections to the original commit and then disposes of the superfluous band-aid commit. (Large preview)

We can go through a practical example together! Let’s say that the selected commit here is broken.

The selected commit is incorrect — and we’re going to fix it in an elegant way. (Large preview)

Let’s also say that I have prepared changes in a file named error.html that will solve the problem. Here’s the first step we need to make:

 

$ git add error.html$ git commit --fixup 2b504bee

We’re creating a new commit, but we’re telling Git this is a special one: it’s a fix for an old commit with the specified SHA-1 hash (2b504bee in this case).

The second step, now, is to start an Interactive Rebase session — because fixup belongs to the big toolset of Interactive Rebase.

$ git rebase -i --autosquash 0023cddd

Two things are worth explaining about this command. First, why did I provide 0023cddd as the revision hash here? Because we need to start our Interactive Rebase session at the parent commit of our broken fellow.

Second, what is the --autosquash option for? It takes a lot of work off our shoulders! In the editor window that now opens, everything is already prepared for us:

The Interactive Rebase session window (Large preview)

Thanks to the --autosquash option, Git has already done the heavy lifting for us:

  1. Marcó nuestro pequeño compromiso de curita con la fixuppalabra clave acción. De esa manera, Git lo combinará con la confirmación directamente arriba y luego lo descartará.
  2. También reordenó las líneas en consecuencia, moviendo nuestro compromiso de curita directamente debajo del compromiso que queremos arreglar (nuevamente: ¡ fixupfunciona combinando el compromiso marcado con el de arriba !).

En resumen: ¡No nos queda más que cerrar la ventana!

Echemos un vistazo final al resultado final.

  • El compromiso anteriormente roto está arreglado: ahora contiene los cambios que preparamos en nuestro compromiso de curita.
  • Se ha descartado la fea confirmación de curita: el historial de confirmaciones es limpio y fácil de leer, como si no hubiera ocurrido ningún error.

El resultado final después de usar la herramienta de reparación: ¡un historial de confirmaciones limpio! ( Vista previa grande )

Saber deshacer errores es un superpoder

¡Felicidades! ¡Ahora puedes salvar tu cuello en muchas situaciones difíciles! Realmente no podemos evitar estas situaciones: no importa nuestra experiencia como desarrolladores, los errores son simplemente parte del trabajo. Pero ahora que sabes cómo afrontarlos, podrás afrontarlos con un ritmo cardíaco relajado.

Si desea obtener más información sobre cómo deshacer errores con Git, puedo recomendar el " Kit de primeros auxilios para Git " gratuito, una serie de videos cortos sobre exactamente este tema.

Diviértete cometiendo errores y, por supuesto, deshaciéndolos con facilidad.

(vf, il)Explora más en

  • git
  • Herramientas
  • Guías
  • javascript





Tal vez te puede interesar:

  1. ¿Deberían abrirse los enlaces en ventanas nuevas?
  2. 24 excelentes tutoriales de AJAX
  3. 70 técnicas nuevas y útiles de AJAX y JavaScript
  4. Más de 45 excelentes recursos y repositorios de fragmentos de código

Una guía para deshacer errores con Git (Parte 2)

Una guía para deshacer errores con Git (Parte 2)

Índice Recuperar una rama eliminada usando Reflog

programar

es

https://aprendeprogramando.es/static/images/programar-una-guia-para-deshacer-errores-con-git-parte-2-1100-0.jpg

2024-05-22

 

Una guía para deshacer errores con Git (Parte 2)
Una guía para deshacer errores con Git (Parte 2)

Si crees que alguno de los contenidos (texto, imagenes o multimedia) en esta página infringe tus derechos relativos a propiedad intelectual, marcas registradas o cualquier otro de tus derechos, por favor ponte en contacto con nosotros en el mail [email protected] y retiraremos este contenido inmediatamente

 

 

Top 20