Me gustaría mover los últimos commits que he comprometido a master a una nueva rama y volver a master antes de que se realicen esos commits. Desafortunadamente, mi Git-fu no es lo suficientemente fuerte todavía, ¿alguna ayuda?

Es decir, ¿cómo puedo ir de esto?

master A - B - C - D - E

¿a esto?

newbranch     C - D - E
             /
master A - B 

Mudarse a una sucursal existente

Si desea mover sus confirmaciones a una rama existente , se verá así:

git checkout existingbranch
git merge master         # Bring the commits here
git checkout master
git reset --keep HEAD~3  # Move master back by 3 commits.
git checkout existingbranch

La --keepopción conserva los cambios no confirmados que pueda tener en archivos no relacionados, o aborta si esos cambios tendrían que sobrescribirse, de manera similar a lo que git checkouthace. Si aborta, git stashcambia y vuelve a intentarlo, o usa --hardpara perder los cambios (¡incluso de archivos que no cambiaron entre las confirmaciones!)

Mudarse a una nueva sucursal

Este método funciona creando una nueva rama con el primer comando ( git branch newbranch) pero sin cambiar a él. Luego, retrocedemos la rama actual (maestra) y cambiamos a la nueva rama para continuar trabajando.

git branch newbranch      # Create a new branch, containing all current commits
git reset --keep HEAD~3   # Move master back by 3 commits (Make sure you know how many commits you need to go back)
git checkout newbranch    # Go to the new branch that still has the desired commits
# Warning: after this it's not safe to do a rebase in newbranch without extra care.

Pero asegúrese de cuántas confirmaciones para volver. Alternativamente, en lugar de HEAD~3, simplemente puede proporcionar el hash de la confirmación (o la referencia como origin/master) a la que desea volver, por ejemplo:

git reset --keep a1b2c3d4

ADVERTENCIA: con Git versión 2.0 y posteriores, si luego se agrega git rebasela nueva rama a la rama original ( master), es posible que necesite una --no-fork-pointopción explícita durante el rebase para evitar perder las confirmaciones que movió de la rama maestra. Tenerlo lo branch.autosetuprebase alwayshace más probable. Ver la respuesta de John Mellor para más detalles.

Para aquellos que se preguntan por qué funciona (como estaba al principio):

Desea volver a C y mover D y E a la nueva rama. Esto es lo que parece al principio:

A-B-C-D-E (HEAD)
        ↑
      master

Después git branch newBranch:

    newBranch
        ↓
A-B-C-D-E (HEAD)
        ↑
      master

Después git reset --hard HEAD~2:

    newBranch
        ↓
A-B-C-D-E (HEAD)
    ↑
  master

Como una rama es solo un puntero, el maestro señaló la última confirmación. Cuando creó newBranch , simplemente creó un nuevo puntero a la última confirmación. Luego, utilizando git reset, movió el puntero maestro hacia atrás dos confirmaciones. Pero como no movió newBranch , todavía señala la confirmación que hizo originalmente.

En general...

El método expuesto por sykora es la mejor opción en este caso. Pero a veces no es lo más fácil y no es un método general. Para un método general, use git cherry-pick :

Para lograr lo que OP quiere, es un proceso de 2 pasos:

Paso 1: tenga en cuenta qué confirmaciones del maestro desea en un newbranch

Ejecutar

git checkout master
git log

Tenga en cuenta los hashes de (digamos 3) confirmaciones que desea newbranch. Aquí usaré:
C commit: 9aa1233
D commit: 453ac3d
E commit:612ecb3

Nota: Puede usar los primeros siete caracteres o el hash de confirmación completo

Paso 2 - Póngalos en el newbranch

git checkout newbranch
git cherry-pick 612ecb3
git cherry-pick 453ac3d
git cherry-pick 9aa1233

O (en Git 1.7.2+, use rangos)

git checkout newbranch
git cherry-pick 612ecb3~1..9aa1233

git cherry-pick aplica esos tres commits a newbranch.

Otra forma de hacer esto, usando solo 2 comandos. También mantiene intacto su árbol de trabajo actual.

git checkout -b newbranch # switch to a new branch
git branch -f master HEAD~3 # make master point to some older commit

Versión anterior - antes de aprender sobregit branch -f

git checkout -b newbranch # switch to a new branch
git push . +HEAD~3:master # make master point to some older commit 

Poder pushhacerlo .es un buen truco para saber.

¡La mayoría de las respuestas anteriores son peligrosamente incorrectas!

No hagas esto:

git branch -t newbranch
git reset --hard HEAD~3
git checkout newbranch

¡Como la próxima vez que ejecute git rebase(o git pull --rebase) esos 3 commits serían descartados en silencio newbranch! (ver explicación a continuación)

En cambio, haz esto:

git reset --keep HEAD~3
git checkout -t -b newbranch
git cherry-pick ..HEAD@{2}

• Primero descarta las 3 confirmaciones más recientes ( --keepes como --hard, pero más seguro, ya que falla en lugar de descartar los cambios no confirmados).
• Luego se bifurca newbranch.
• Luego, elige los 3 commits nuevamente newbranch. Dado que una rama ya no hace referencia a ellos, lo hace mediante el uso de refit de git : HEAD@{2}es el compromiso que HEADsolía referirse a 2 operaciones hace, es decir, antes de 1. desprotegido newbranchy 2. utilizado git resetpara descartar los 3 compromisos.

Advertencia: el reflog está habilitado de forma predeterminada, pero si lo ha deshabilitado manualmente (por ejemplo, utilizando un repositorio git "desnudo"), no podrá recuperar los 3 commits después de ejecutarlo git reset --keep HEAD~3.

Una alternativa que no depende del reflog es:

# newbranch will omit the 3 most recent commits.
git checkout -b newbranch HEAD~3
git branch --set-upstream-to=oldbranch
# Cherry-picks the extra commits from oldbranch.
git cherry-pick ..oldbranch
# Discards the 3 most recent commits from oldbranch.
git branch --force oldbranch oldbranch~3

(si lo prefiere, puede escribir @{-1}, la rama previamente extraída, en lugar de oldbranch).

Explicación técnica

¿Por qué git rebasedescartar los 3 commits después del primer ejemplo? Es porque git rebasesin argumentos habilita la --fork-pointopción por defecto, que usa el registro local para tratar de ser robusto contra la rama ascendente que se empuja a la fuerza.

Supongamos que ramificó origen / maestro cuando contenía confirmaciones M1, M2, M3, y luego realizó tres confirmaciones usted mismo:

M1--M2--M3  <-- origin/master
         \
          T1--T2--T3  <-- topic

pero luego alguien reescribe el historial presionando forzar origin / master para eliminar M2:

M1--M3'  <-- origin/master
 \
  M2--M3--T1--T2--T3  <-- topic

Usando su reflog local, git rebasepuede ver que se bifurcó de una encarnación anterior de la rama de origen / maestra, y por lo tanto, las confirmaciones de M2 ​​y M3 no son realmente parte de su rama de tema. Por lo tanto, se supone razonablemente que, dado que M2 se eliminó de la rama ascendente, ya no lo desea en su rama temática una vez que la rama temática se haya modificado:

M1--M3'  <-- origin/master
     \
      T1'--T2'--T3'  <-- topic (rebased)

Este comportamiento tiene sentido y, por lo general, es lo que se debe hacer al rebasar.

Entonces, la razón por la que fallan los siguientes comandos:

git branch -t newbranch
git reset --hard HEAD~3
git checkout newbranch

es porque dejan el reflog en el estado incorrecto. Git ve newbranchque se ha bifurcado de la rama ascendente en una revisión que incluye los 3 commits, luego reset --hardreescribe el historial del upstream para eliminar los commits, por lo que la próxima vez que git rebaselo ejecutes los descarta como cualquier otro commit que se haya eliminado del upstream.

Pero en este caso particular, queremos que esas 3 confirmaciones se consideren como parte de la rama del tema. Para lograr eso, necesitamos bifurcar el flujo ascendente en la revisión anterior que no incluye las 3 confirmaciones. Eso es lo que hacen mis soluciones sugeridas, por lo tanto, ambos dejan el registro en el estado correcto.

Para obtener más detalles, consulte la definición de --fork-pointen los documentos git rebase y git merge-base .

Solución mucho más simple usando git stash

Aquí hay una solución mucho más simple para los compromisos con la rama incorrecta. Comenzando en la rama masterque tiene tres confirmaciones erróneas:

git reset HEAD~3
git stash
git checkout newbranch
git stash pop

¿Cuándo usar esto?

• Si su propósito principal es retroceder master
• Desea conservar los cambios de archivo.
• No te importan los mensajes en las confirmaciones erróneas
• Aún no has empujado
• Quieres que sea fácil de memorizar
• No desea complicaciones como ramas temporales / nuevas, encontrar y copiar hashes de confirmación y otros dolores de cabeza

Qué hace esto, por número de línea

1. Deshace las últimas tres confirmaciones (y sus mensajes) master, pero deja intactos todos los archivos de trabajo
2. Guarda todos los cambios del archivo de trabajo, haciendo que el masterárbol de trabajo sea exactamente igual al estado HEAD ~ 3
3. Cambia a una sucursal existente newbranch
4. Aplica los cambios escondidos a su directorio de trabajo y borra el alijo

Ahora puede usar git addy git commitcomo lo haría normalmente. Se agregarán todos los nuevos commits newbranch.

Lo que esto no hace

• No deja ramas aleatorias temporales que abarrotan tu árbol
• No conserva los mensajes de confirmación erróneos, por lo que deberá agregar un nuevo mensaje de confirmación a esta nueva confirmación
• ¡Actualizar! Use la flecha hacia arriba para desplazarse por el búfer de comandos para volver a aplicar la confirmación anterior con su mensaje de confirmación (gracias @ARK)

Metas

El OP declaró que el objetivo era "recuperar el master antes de que se realizaran esas confirmaciones" sin perder los cambios y esta solución lo hace.

Hago esto al menos una vez a la semana cuando accidentalmente hago nuevos commits en masterlugar de develop. Por lo general, solo tengo un commit para revertir, en cuyo caso usar git reset HEAD^en la línea 1 es una forma más simple de revertir solo un commit.

No hagas esto si empujaste los cambios del maestro hacia arriba

Alguien más puede haber sacado esos cambios. Si solo está reescribiendo a su maestro local, no hay ningún impacto cuando se empuja hacia arriba, pero enviar un historial reescrito a los colaboradores puede causar dolores de cabeza.

Esto no los "mueve" en el sentido técnico, pero tiene el mismo efecto:

A--B--C  (branch-foo)
 \    ^-- I wanted them here!
  \
   D--E--F--G  (branch-bar)
      ^--^--^-- Opps wrong branch!

While on branch-bar:
$ git reset --hard D # remember the SHAs for E, F, G (or E and G for a range)

A--B--C  (branch-foo)
 \
  \
   D-(E--F--G) detached
   ^-- (branch-bar)

Switch to branch-foo
$ git cherry-pick E..G

A--B--C--E'--F'--G' (branch-foo)
 \   E--F--G detached (This can be ignored)
  \ /
   D--H--I (branch-bar)

Now you won't need to worry about the detached branch because it is basically
like they are in the trash can waiting for the day it gets garbage collected.
Eventually some time in the far future it will look like:

A--B--C--E'--F'--G'--L--M--N--... (branch-foo)
 \
  \
   D--H--I--J--K--.... (branch-bar)

Para hacer esto sin reescribir el historial (es decir, si ya ha empujado los commits):

git checkout master
git revert <commitID(s)>
git checkout -b new-branch
git cherry-pick <commitID(s)>

¡Ambas ramas pueden ser empujadas sin fuerza!

Acabo de esta situación:

Branch one: A B C D E F     J   L M  
                       \ (Merge)
Branch two:             G I   K     N

Yo actué:

git branch newbranch 
git reset --hard HEAD~8 
git checkout newbranch

Esperaba que commit fuera el HEAD, pero commit L es ahora ...

Para asegurarse de aterrizar en el lugar correcto de la historia, es más fácil trabajar con el hash del commit

git branch newbranch 
git reset --hard #########
git checkout newbranch

¿Cómo puedo ir de esto?

A - B - C - D - E 
                |
                master

¿a esto?

A - B - C - D - E 
    |           |
    master      newbranch

Con dos comandos

• git branch -m master newbranch

dando

A - B - C - D - E 
                |
                newbranch

y

• git branch master B

dando

A - B - C - D - E
    |           |
    master      newbranch

Si solo necesita mover todas sus confirmaciones no apresuradas a una nueva sucursal , entonces solo necesita,

1. crear una nueva rama de la actual:git branch new-branch-name

2. empuja tu nueva sucursal :git push origin new-branch-name

3. revierta su rama anterior (actual) al último estado de inserción / estable:git reset --hard origin/old-branch-name

Algunas personas también tienen otros en upstreamslugar de origin, deberían usarupstream

1) Crea una nueva rama, que mueve todos tus cambios a new_branch.

git checkout -b new_branch

2) Luego regresa a la rama anterior.

git checkout master

3) Hacer git rebase

git rebase -i <short-hash-of-B-commit>

4) Luego, el editor abierto contiene los últimos 3 datos de confirmación.

...
pick <C's hash> C
pick <D's hash> D
pick <E's hash> E
...

5) Cambie picka dropen todos esos 3 commits. Luego guarde y cierre el editor.

...
drop <C's hash> C
drop <D's hash> D
drop <E's hash> E
...

6) Ahora se eliminan los últimos 3 commits de la rama actual ( master). Ahora empuje la rama con fuerza, con un +signo antes del nombre de la rama.

git push origin +master

Puedes hacer esto, solo 3 pasos simples que utilicé.

1) crea una nueva sucursal donde quieras confirmar tu actualización reciente.

git branch <branch name>

2) Encuentre el ID de confirmación reciente para confirmar en una nueva sucursal.

git log

3) Copie esa nota de identificación de confirmación de que la lista de confirmación más reciente tiene lugar en la parte superior. para que pueda encontrar su compromiso. también lo encuentras por mensaje.

git cherry-pick d34bcef232f6c...

También puede proporcionar algún tipo de ID de confirmación.

git cherry-pick d34bcef...86d2aec

Ahora tu trabajo hecho. Si eligió la identificación correcta y la rama correcta, entonces tendrá éxito. Entonces, antes de hacer esto, ten cuidado. De lo contrario, puede ocurrir otro problema.

Ahora puedes empujar tu código

git push

Otra forma de hacer esto:

[1] Cambie el nombre de la masterrama a su newbranch(suponiendo que esté en la masterrama):

git branch -m newbranch

[2] Crea una masterrama desde el commit que desees:

git checkout -b master <seven_char_commit_id>

por ejemplo, git checkout -b master a34bc22