git - crear - moviendo cambios comprometidos(pero no empujados) a una nueva rama después de tirar

git push

Question

He hecho un poco de trabajo ("Tu sucursal está por delante de ''origen / maestro'' con 37 confirmaciones ''") que realmente debería haber ingresado en su propia sucursal en lugar de en el master . Estas confirmaciones solo existen en mi máquina local y no han sido empujadas a origin , pero la situación es algo complicada ya que otros desarrolladores han estado presionando a origin/master y he eliminado esos cambios.

¿Cómo muevo retroactivamente mis 37 confirmaciones locales a una nueva sucursal? Según los documentos, parece que git rebase --onto my-new-branch master o ...origin/master debería hacer esto, pero ambos solo me dan el error "fatal: se necesita una sola revisión". man git-rebase no dice nada sobre proporcionar una revisión de rebase y sus ejemplos no lo hacen, por lo que no tengo idea de cómo resolver este error.

(Tenga en cuenta que esto no es un duplicado de Mover trabajo no comprometido existente a una nueva sucursal en Git o ¿Cómo combinar mis cambios locales no confirmados a otra sucursal de Git? Ya que esas preguntas se refieren a cambios no confirmados en el árbol de trabajo local, no a cambios que hayan sido cometido localmente)

Answer 1

1. Checkout nueva copia de sus fuentes

   git clone ........

2. Hacer rama desde la posición deseada

   git checkout {position} git checkout -b {branch-name}

3. Añadir repositorio remoto

   git remote add shared ../{original sources location}.git

4. Obtener fuentes remotas

   git fetch shared

5. Checkout rama deseada

   git checkout {branch-name}

6. Fusionar fuentes

   git merge shared/{original branch from shared repository}

Answer 2

Alternativamente, justo después de que te comprometas con la rama incorrecta, sigue estos pasos:

1. git log
2. git diff {previous to last commit} {latest commit} > your_changes.patch
3. git reset --hard origin/{your current branch}
4. git checkout -b {new branch}
5. git apply your_changes.patch

Puedo imaginar que hay un enfoque más simple para los pasos uno y dos.

Answer 3

Esto debería estar bien, ya que aún no has introducido tus confirmaciones en ningún otro lugar, y eres libre de volver a escribir el historial de tu sucursal después del origin/master . Primero ejecutaría un git fetch origin para asegurarme de que origin/master está actualizado. Suponiendo que actualmente estés en master , deberías poder hacer:

git rebase origin/master

... que reproducirá todas sus confirmaciones que no están en origin/master en origin/master . La acción predeterminada de rebase es ignorar las combinaciones de combinaciones (por ejemplo, aquellas que probablemente haya introducido su git pull ) y solo intentará aplicar el parche introducido por cada una de sus confirmaciones en origin/master . (Es posible que tenga que resolver algunos conflictos en el camino). Luego, puede crear su nueva rama en función del resultado:

git branch new-work

... y luego restablecer su master nuevo a origin/master :

# Use with care - make sure "git status" is clean and you''re still on master:
git reset --hard origin/master

Al hacer este tipo de manipular ramas con git branch , git reset , etc., me parece útil mirar con frecuencia el gráfico de compromiso con gitk --all o una herramienta similar, solo para comprobar que entiendo a dónde apuntan todos los diferentes refs .

Alternativamente, podría haber creado una rama de tema en función de dónde se encuentra su maestro en primer lugar ( git branch new-work-including-merges ) y luego reiniciar el master como se master anteriormente. Sin embargo, dado que su rama temática incluirá fusiones desde el origin/master y aún no ha impulsado sus cambios, sugeriría hacer una rebase para que el historial sea más ordenado. (Además, cuando finalmente fusiones tu rama de tema con la maestra, los cambios serán más obvios).

Answer 4

Me quedé con el mismo problema. He encontrado la solución más fácil que me gusta compartir.

1) Crea una nueva rama con tus cambios.

git checkout -b mybranch

2) Presione el nuevo código de sucursal en el servidor remoto.

git push origin mybranch

3) Salida de nuevo a la rama principal.

git checkout master

4) Restaure el código de la rama maestra con el servidor remoto y elimine la confirmación local.

git reset --hard origin/master

Answer 5

Para mi esta fue la mejor manera:

1. Compruebe si hay cambios y fusionar conflictos git fetch
2. Crear una nueva rama git branch my-changes y empujar a remoto
3. Cambie en sentido ascendente a la nueva rama creada git master -u upstream-branch remotes/origin/my-changes
4. Empuje sus compromisos a la nueva rama aguas arriba.
5. Vuelva al git branch master --set-upstream-to remotes/origin/master anterior anterior de git branch master --set-upstream-to remotes/origin/master

Answer 6

Qué pasa:

1. Rama de la CABEZA actual.
2. Asegúrese de que está en el maestro , no su nueva rama.
3. git reset vuelve a la última confirmación antes de comenzar a hacer cambios.
4. git pull para volver a tirar solo los cambios remotos que tiró con el reinicio.

¿O explotará cuando intentes volver a combinar la rama?

Answer 7

Si tienes un número bajo de confirmaciones y no te importa si se combinan en un mega-confirmación, esto funciona bien y no da tanto miedo como hacer git rebase :

desestabilice los archivos (reemplace 1 con # de confirmaciones)

git reset --soft HEAD~1

crear una nueva rama

git checkout -b NewBranchName

añadir los cambios

git add -A

hacer un compromiso

git commit -m "Whatever"

Answer 8

Un enfoque más simple, que he estado usando (asumiendo que desea mover 4 confirmaciones):

git format-patch HEAD~4

(Busque en el directorio desde el que ejecutó el último comando para los 4 archivos .patch )

git reset HEAD~4 --hard

git checkout -b tmp/my-new-branch

Entonces:

git apply /path/to/patch.patch

En el orden que quisieras.

Answer 9

Una forma más de suponer que branch1 - es una rama con cambios confirmados branch2 - es una rama deseable

git fetch && git checkout branch1
git log

Seleccione los ID de confirmación que necesita mover

git fetch && git checkout branch2
git cherry-pick commit_id_first..commit_id_last
git push

Ahora revertir confirmaciones no presionadas de la rama inicial

git fetch && git checkout branch1
git reset --soft HEAD~1