Git: la he liado parda

Aquí os dejo el vídeo de la presentación que hice ayer (24 de abril de 2013) en el grupo de desarrolladores de Symfony de Madrid.

Una presentación de una hora en la que hablamos de las herramientas que nos da git para no tener que recurrir al famoso borrar-y-volver-a-clonar-repositorio para recuperar nuestro repo cuando nos equivocamos.

Durante la presentación hacemos varias demos:

  • Cómo detener un merge que nos ha dado conflictos
  • Cómo deshacer un merge una vez finalizado
  • Cómo deshacer un rebase que hemos hecho al revés, sobreescribiendo la historia del repositorio
  • Cómo usar git-bisect para encontrar un bug
  • Cómo usar git-revert para solucionarlo

¡No está mal para una hora! Espero que os guste y os resulte útil.

Aprovechamos para recordaros que en Aprendegit estamos siempre dispuestos para dar charlas y presentaciones sobre nuestra herramienta favorita. Así que si quieres que vayamos a hablar de git a cualquier sitio, sólo tienes que proponernoslo 😉

7 pensamientos en “Git: la he liado parda

  1. Joan

    Muy buen video, de nuevo 😉 Solo una duda con el último ejemplo, el del rebase al revés: no sería mas directo canviar la referencia de master con un reset –hard al commit que sabemos cual es después de ver el logs/ref?

    Responder
    1. alfonso Autor

      Hola Joan:

      Efectivamente, es lo mismo que hice yo en la presentación (al final cambié de nombre a la rama “prueba” y la llamé master). Lo hice en dos pasos porque quería que se viese expresamente los dos grupos de commits en pantalla.

      Responder
      1. Joan

        Ah ok, perfecto. Por cierto, solo por curiosidad: ¿qué solución planteaste a la bonus (hacer commits en la rama que no toca)? Así rápido se me ocurre:

        1: reset –hard al commit del principio
        2: cherry-picking con todos los commits que has hecho (mirándolos previamente en el log o en el logs/ref)

        Qué solución propusiste tú? Hay algo más “limpio” que tener que pasar todos los hashs de los commits al cherry-pick?

        Responder
        1. alfonso Autor

          Hola de nuevo. Sí, la solución que propongo es esa, aunque en realidad no hace falta recurrir al reflog porque creo una referencia adicional para no tener que hacerlo. Los pasos que sigo son:

          • Creo una rama nueva que llamo ‘old’ que apunta al HEAD justo después de hacer los commits, así no tengo que estar mirando el reflog
          • Hago el reset de la rama al punto anterior para dejarla como estaba
          • Me voy a la rama correcta en la que deberían estar los commits
          • Hago un rebase o un cherry pick de los commits de la rama old
          • Borro la rama old

          Alfonso

          Responder
          1. Joan

            Ah, cierto. Está bien lo de crearte una nueva rama ya que después puedes hacer rebase directo o interactivo desde la misma a la rama correcta.

            Muchas gracias!

  2. Pingback: 6 motivos por los que git no es un sistema de backup | Aprende GIT

  3. Pingback: Cómo deshacer un commit en git

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *