Cómo mover los cambios fuera de la rama principal

7 minutos de lectura

avatar de usuario
Meltemi

Pregunta básica pero esto me pasa todo el tiempo:

  • Hacer cambios en un working-branch
  • Cambiar a master
  • git merge working-branch
  • git push
  • cap deploy(poner en escena)
  • hacer una nueva taza de té

luego vuelvo y pienso en otra cosa y empiezo a hacer algunos cambios… mientras aún estoy en el maestro.

¿Cuál es una manera fácil de:

  1. evitar ediciones directas en el maestro (advertencia quizás)
  2. mover todas las ediciones a working-branch Y limpio master para poder seguir editando working-branch o
  3. girar las ediciones en una rama completamente nueva new-working-branch y luego descartar working-branch?

Se arriesgó y probó la recomendación en la última parte de la sección “Sucursales” de esta página ¡¿Pero eso acaba de borrar TODAS mis ediciones?! Quizá porque después git branch dubious-experiment y git checkout master la git status en ambas ramas era idéntico (no ‘limpio’ en el maestro). Asi que git reset --hard <SHA1sum> borró todos los cambios en ambos?!

  git branch dubious-experiment

  M---N-----O----P---Q ("master" and "dubious-experiment")

  git checkout master

  # Be careful with this next command: make sure "git status" is
  # clean, you're definitely on "master" and the
  # "dubious-experiment" branch has the commits you were working
  # on first...

  git reset --hard <SHA1sum of commit N>

avatar de usuario
Cronial

Según su descripción, asumo que aún no ha realizado ningún cambio, ¿es correcto?

En caso afirmativo, aquí están sus respuestas:

Cómo evitar ediciones directas al maestro

Necesitará configurar eso en su editor, pero probablemente será difícil. Mostrar su rama actual en su indicador y su editor ayuda mucho.

Cómo mover los cambios a una nueva rama new-working-branch y luego descartar working-branch

git checkout -b new-working-branch
git add …
git commit -m "mycommit" 

Como aún no ha enviado nada al maestro, no necesita cambiar nada en el maestro. Ahora puede descartar su rama de trabajo si lo desea.

Cómo mover los cambios a working-branch

git checkout -b temp-branch
git add …
git commit -m "mycommit" 
git rebase --onto working-branch master
git checkout working-branch
git reset --hard temp-branch
git branch -d temp-branch

Si sus cambios no entran en conflicto con los cambios que están en el maestro, pero no en la rama de trabajo, esto se puede hacer mucho más simple:

git stash
git checkout working-branch
git stash pop

avatar de usuario
kurzedmetal

Si ya comprometió sus cambios a master pero no empujó a ningún lado…

crear una nueva rama para los últimos cambios

git checkout -b newfeat master

reproducir todos los cambios (mover las confirmaciones) encima de su working-branch rama

git rebase --onto working-branch origin/master newfeat

cambiar a master rama y restablecerlo al estado de la última pulsación

git checkout master
git reset --hard origin/master

En este punto tienes:

  • master apuntando a la última confirmación empujada (origin/master)
  • working-branch nunca cambió
  • un nuevo newfeat rama que contiene todas las nuevas confirmaciones y está por delante de working-branch.

  • Pude omitir el paso de rebase, pero esto fue muy útil. ¡Gracias!

    –Walter Nissen

    1 de agosto de 2020 a las 0:42

Usé para casos similares:

git branch -f <branch-name>
git checkout <branch-name>

o

git checkout -B <branch-name>

.

Ambas variantes mueven la rama branch-name a su compromiso actual sin reiniciar su árbol.

Generalmente recomiendo la siguiente configuración de Git:

git config push.default nothing

Con esto, al menos tendrás que nombrar la rama cuando presiones. No impedirá que te comprometas con la maestría localmente, pero cuando te des cuenta de que lo has hecho, puedes mover esas confirmaciones a una rama sin afectar a nadie más.

avatar de usuario
DigitalRoss

Acostúmbrate a escribir $ git status antes de hacer un comando git que modificará algo.

Dado eso, probablemente haya editado su archivo pero no lo haya registrado, porque ejecutaría git status antes del compromiso. En este caso, git hace lo correcto si solo cambia de rama y luego confirma.

Si usted tener disparó un compromiso al maestro, luego simplemente mueva el archivo entre las ramas con algo como esto:

 $ git checkout --patch master <somefile>

Realmente no tiene que restablecer el maestro si solo va a fusionar el mismo archivo con él, pero dado que presumiblemente aún no ha enviado nada, debe restablecer sus sucursales de seguimiento remoto …

$ git reset master origin/master
$ git reset stage origin/stage # whatever

  • Creo que me estoy perdiendo algo conceptual sobre Git?!? Disculpe mi ignorancia, pero ¿qué quiere decir con “git hace lo correcto si solo cambia de rama”?

    – Meltemi

    24 de enero de 2013 a las 17:34

  • -1 – simplemente “robar” un archivo del maestro con git checkout es peligroso: el maestro puede contener cambios que no están en la rama de trabajo, causando un desastre. Correr git reset sin que --hard en su mayoría será muy confuso.

    – Cronial

    24 de enero de 2013 a las 23:07

  • @Meltemi, cambiar un archivo mientras la rama está desprotegida no bloquea esos cambios en el maestro. Si realiza el pago en otra rama, puede simplemente confirmar sus cambios y el maestro no se dará cuenta de la actividad. @Chronial, bueno, el valor predeterminado --mixed dejará sus cambios disponibles para confirmar en la rama de tema correcta.

    – DigitalRoss

    24 de enero de 2013 a las 23:21

avatar de usuario
Comunidad

1. evitar ediciones directas en el maestro (advertencia quizás)

No eres el único que quiere esto. La mejor idea que he encontrado es poner la rama git directamente en el indicador de shell. Mi mensaje se ve así:

[[email protected] directory:git_branch]

También coloreo la entrada git_branch, por lo que es bastante obvio en lo que estoy trabajando en todo momento. Estos dos enlaces en Stack Overflow deberían ayudarlo con su aviso.

2. para mover todas las ediciones a la rama de trabajo y borrar el maestro para poder continuar editando en la rama de trabajo

o

3. para convertir las ediciones en una rama completamente nueva new-working-branch y luego descartar working-branch?

Estas son realmente la misma pregunta: cómo mover los cambios del maestro a una rama, ya sea una rama antigua o una rama nueva. Y tu propia respuesta es correcta. Aunque a segunda vista, suponiendo que esté en el maestro, podría simplemente ejecutar:

git branch new_branch
git reset --hard origin/master

Prefiero simplemente restablecer maestro a origen/maestro en lugar de preocuparme por un SHA de confirmación específico. Pero tus pasos fueron esencialmente correctos. En cuanto a por qué perdiste los cambios, tendría que pensar que por error no había un puntero de bifurcación a Q cuando reiniciaste el maestro. Ninguna otra explicación tiene sentido. Nuevamente, tener el indicador de shell de la sucursal ayudará a evitar estos errores. Además, soy un gran fanático de usar gitk o git log –graph para verificar dónde están mis ramas antes de moverlas. Como no puedo usar gitk fácilmente en el trabajo, tengo un alias en mi .gitconfig llamado “graph”, que es esencialmente una versión de línea de comandos:

[alias]
    graph = log --graph --all --date=short --pretty=format':%C(yellow)%h%Cblue%d%Creset %s %Cgreen %aN, %ad%Creset'

Esto mostrará el gráfico en el extremo izquierdo, el SHA de confirmación en amarillo, las ramas en azul, el mensaje de confirmación en blanco y el autor y la fecha en verde. Por supuesto, esto se puede modificar a su gusto.

[edited to make the above commands simpler]

==============================

En respuesta al siguiente comentario:

Empezar con

A-B < origin/master
   \
    C-D < master

Ahora realiza git checkout -b new_branch

A-B < origin/master
   \
    C-D < master, new_branch

Ahora pago maestro, git checkout master. Tenga en cuenta que git checkout -b new_branch && git checkout master es lo mismo que git branch new_branch si ya estabas en master. Edité la respuesta anterior para reflejar esto.

Ahora restablezca el maestro a origen/maestro, git reset --hard origin/master

A-B < master, origin/master
   \
    C-D < new_branch

Debido a que tenía una rama (nueva_rama) apuntando a D, no se pierden los cambios. Si he cometido un error, explique dónde.

  • Creo que me estoy perdiendo algo conceptual sobre Git?!? Disculpe mi ignorancia, pero ¿qué quiere decir con “git hace lo correcto si solo cambia de rama”?

    – Meltemi

    24 de enero de 2013 a las 17:34

  • -1 – simplemente “robar” un archivo del maestro con git checkout es peligroso: el maestro puede contener cambios que no están en la rama de trabajo, causando un desastre. Correr git reset sin que --hard en su mayoría será muy confuso.

    – Cronial

    24 de enero de 2013 a las 23:07

  • @Meltemi, cambiar un archivo mientras la rama está desprotegida no bloquea esos cambios en el maestro. Si realiza el pago en otra rama, puede simplemente confirmar sus cambios y el maestro no se dará cuenta de la actividad. @Chronial, bueno, el valor predeterminado --mixed dejará sus cambios disponibles para confirmar en la rama de tema correcta.

    – DigitalRoss

    24 de enero de 2013 a las 23:21

¿Ha sido útil esta solución?