Me ha gustado mucho el artículo, enhorabuena 🙂 . Yo publiqué un artículo en mi blog para aprender a usar Git desde 0 y con un pequeño ejemplo real de un sencillísimo desarrollo web. Dejo la URL por si es útil para otros visitantes.

https://www.raulprietofernandez.net/blog/webs/como-usar-git-para-el-desarrollo-web-conceptos-y-ejemplo

Saludos! 😀

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!

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

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?

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.